[SIPForum-discussion] Help with Request URI and To Field

Larry Gray lgray at bgibson.com
Tue Sep 8 19:23:43 UTC 2015

Hi Everyone,

I'm new to the forums and I'm hopeful to expand my knowledge here.  I have situation I can't wrap my head around.  I have a SIP trunk provider to PBX connection through a local Border Gateway.

Provider<====>Border Gateway<====>PBX

When the provider send us an incoming call, we get the following in the invite:
INVITE: xxx-xxx-xxxx at x.x.79.98<mailto:xxx-xxx-xxxx at x.x.79.98>
To: xxx-xxx-xxxx at x.x.76.80<mailto:xxx-xxx-xxxx at x.x.76.80>
From: yyy-yyy-yyyy at x.x.76.80<mailto:yyy-yyy-yyyy at x.x.76.80>

The call sets up fine, even though the carrier is using their IP in the To header.  But, eventually, when the PBX goes to put someone on hold, it sends out a re-invite message:
INVITE: yyy-yyy-yyyy at x.x.76.80<mailto:yyy-yyy-yyyy at x.x.76.80>
To: yyy-yyy-yyyy at x.x.76.80<mailto:yyy-yyy-yyyy at x.x.76.80>
From: yyy-yyy-yyyy at 79.98<mailto:yyy-yyy-yyyy at 79.98>

Where the carrier then responds with SIP 481 Call/Transaction does not exist because the From header in the Re-invite doesn't match the To headers in the call setup.

I'm trying to wrap my head around the RFC for the Request URI vs the To header.  I'm not really sure what to tell the carrier, because I can't change the fact that the PBX will always be using its own public IP in the From header.  Is the carrier doing something wrong that I should point out?  I should mention, outbound calls work perfectly and all of the headers reference the appropriate UA's correctly, both in call setup and in re-invites.

[cid:teldata2386dd6]                    Larry  Gray
Phone: (317) 802-2530
Fax: (317) 802-2531
Extension: 22530
E-mail: lgray at bgibson.com
Disclaimer: The information enclosed in this transmission is considered private & confidential and may not be reproduced in any form without the senders permission. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it is prohibited and is unlawful.
Please consider the environment, before printing this email.

Disclaimer added by CodeTwo Exchange Rules 2013

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20150908/b29d222b/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: teldata2386dd6
Type: image/jpeg
Size: 14985 bytes
Desc: teldata2386dd6
URL: <http://sipforum.org/pipermail/discussion/attachments/20150908/b29d222b/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c17f1326-f74b-443b-854f-d8ebfcd977db089b7e
Type: image/gif
Size: 3639 bytes
Desc: c17f1326-f74b-443b-854f-d8ebfcd977db089b7e
URL: <http://sipforum.org/pipermail/discussion/attachments/20150908/b29d222b/attachment-0002.gif>

More information about the discussion mailing list