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

Paul Kyzivat pkyzivat at alum.mit.edu
Tue Sep 15 14:33:57 UTC 2015


On 9/8/15 3:23 PM, Larry Gray wrote:
> 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
>
> x.x.76.80çèx.x.79.98==10.10.2.5çè10.10.2.2

I don't understand what you are trying to indicate above.

> 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.

There is a lot of variety in how sip URIs are handled when the 
source/target is a phone number. What you describe is a bit odd, but not 
so unusual.

You didn't provide some key info:
- the URI from the Contact header
- the tags from the From and to header.
   (The tag= value in the From and To.)
- The Call-ID.

In the initial INVITE, there should be a from-tag but no to-tag. In the 
responses from your end that should be repeated, and a to-tag added. The 
Call-ID, to-tag and from-tag together are called the dialog-id. All 
subsequent requests and responses within that dialog share the same 
dialog id, and should use the same From and To URI. And all the requests 
within the dialog use the Contact URI of the other end as the request-uri.

> 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.

Write back with more detail from the call flow. Then maybe we can 
diagnose what is going on.

> 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.

In theory the from and to URIs don't matter - it is the request URI and 
dialog id that determines the matching of messages to dialogs. But 
historically it was required that the From and To URIs remain unchanged. 
And some implementations may still enforce that.

I'd be surprised if your PBX can't preserve the From and To URIs within 
the dialog. If you can provide complete copies of the messages it would 
help.

	Thanks,
	Paul

> 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.
>
>
> 			Larry Gray
> Technician
> 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*
> www.codetwo.com <http://www.codetwo.com/?sts=2532>
>
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>




More information about the discussion mailing list