headers
Theo Zourzouvillys | 1 Aug 2008 23:26
Picon
Favicon

Re: Proper INVITE To: source

On Thu, Jul 31, 2008 at 1:52 PM, Eric Tamme <etamme <at> gentel.net> wrote:

> 1) Is it correct for the softswitch to translate the dialed number in
> the INVITE but not in the To: ? (This is not a redirect server, its just
> a switch)

That is correct.  The To header is populated by the UAC, and
represents the logical target of the request when it was generated,
not it's current target on a hop-by-hop basis.  That is what the R-URI
(the request URI) is for.

> 2) What is the correct place to be looking for the peer/dialed digits
> To: or in the INVITE ?

The R-URI is the correct place.  A UAC can ostensibly put whatever
value it likes into the To header - and that value is not allowed be
modified by any proxy at all.  The value placed into the To header
field will be the same when it reaches a UAS as when it left the UAC,
for example perhaps because the request was redirected by a proxy.

There is an example of this i've had to regularly point vendors to:
http://wiki.voip.co.uk/sip/matching_using_to_header

 ~ Theo
Permalink | Reply | 0 comments |
headers
KASTURI Narayanan (kasnaray | 3 Aug 2008 13:40
Picon
Favicon

Re: Proper INVITE To: source


> -----Original Message-----
> From: sip-implementors-bounces <at> lists.cs.columbia.edu 
> [mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On 
> Behalf Of Eric Tamme
> Sent: Thursday, July 31, 2008 7:52 AM
> To: Sip-implementors <at> lists.cs.columbia.edu
> Subject: [Sip-implementors] Proper INVITE To: source
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I am working on building a routing engine and have been doing 
> testing with some systems that manipulate the dialed digits: 
> prefixing, stripping digits, etc., to control routing.  They 
> then rewrite the peer in the the INVITE request, but NOT in 
> the To: tag.  Here is an example.
> 
> UA dials: 12316468625535 <at> 1.1.1.1
> 
> Softswitch 1.1.1.1: strips 123 and sends
> 
> INVITE sip:16468625535 <at> 1.1.1.1
> ...
> To: 12316468625535 <at> 1.1.1.1
> 
> So my questions are:
> 
> 1) Is it correct for the softswitch to translate the dialed 
> number in the INVITE but not in the To: ? (This is not a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Tamme | 4 Aug 2008 18:22

Determin upstream signaling device


Im attempting to find a way to determine an upstream devices signaling
IP from sip messaging.  Let me describe the flow

customer -> switch -> routing server

(all terms used below are in the context of the call flow above)

I want to find the signaling IP of the customer.  I have found that if
the switch sends SDP with the INVITE, and the switch is not set to route
media, I can get the customer signaling out of the SDP connection
information.  This however is not a viable solution because it is likely
some customer will be sending media through the switch.

Does any one know of a way to possibly determine the upstream customer
signaling ip from the routing server?

--
Eric Tamme
etamme <at> gentel.net
KeyServer: pgp.mit.edu
Permalink | Reply | 3 comments |
headers
Dale.Worley | 5 Aug 2008 04:30
Picon

Re: Determin upstream signaling device

   From: Eric Tamme <etamme <at> gentel.net>

   Im attempting to find a way to determine an upstream devices signaling
   IP from sip messaging.  Let me describe the flow

Looking at the Contact address in the request probably tells you this.

But what problem are you attempting to solve?  This mechanism is
probably not the solution you are seeking.

Dale
Permalink | Reply | 2 comments |
headers
Bi Ran | 5 Aug 2008 04:39

(no subject)

a52d0ed1e4d9d <at> mail.gmail.com>
Bcc: "garyjin" <garyjin <at> alcatel-lucent.com>
References: <990aed650807160208r7646b7d8rde6a52d0ed1e4d9d <at> mail.gmail.com>
Subject: query about 'npdi' 'rn' 'cpc' and 'cic' parameters
Date: Tue, 5 Aug 2008 10:39:06 +0800
MIME-Version: 1.0
X-Unsent: 1
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 12.0.1606
X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606

Hi all,

Could 'npdi' 'rn' 'cpc' and 'cic' parameters be put into SIP-URI? Or they 
are only allowed in TEL-URI as defined by RFC 4694?
This seems a conflict between standard and implementation. For PSTN to SIP 
(with SIP-URI) calls those parameters are defintely needed.

If they could be added to SIP-URI, can we add them at the end of SIP-URI 
like 'user=phone'? Or we must put them before the ' <at> '.

Thanks,
Bi Ran
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rockson Li (zhengyli | 5 Aug 2008 09:13
Picon
Favicon

question on RFC5057 Multiple Dialog Usages in SIP

Hi folks,

I think the first NOTIFY message should be sent after 2xx(SUBSCRIBE).
This is described in RFC3265 sec3.1.6.2

 
   Note that a NOTIFY message is always sent immediately after any 200-
   class response to a SUBSCRIBE request, regardless of whether the
   subscription has already been authorized.

 
But why in  RFC5057 Figure 3, both F1 and F2 are sent before
200(SUBSCRIBE)?

thanks

-Rockson
Permalink | Reply | 5 comments |
headers
achint.aggarwal | 5 Aug 2008 11:10

My email ID for posting in SIP-Implementors list

Hi!

I have recently subscribed to this forum

My Email ID is : achint.aggarwal <at> wipro.com

regards
Achint Aggarwal

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for
the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any
attachments for the presence of viruses. The company accepts no liability for any damage caused by any
virus transmitted by this email. 

www.wipro.com
Permalink | Reply | 0 comments |
headers
Eric Tamme | 5 Aug 2008 13:57

Re: Determin upstream signaling device


Dale.Worley <at> comcast.net wrote:
>    From: Eric Tamme <etamme <at> gentel.net>
> 
>    Im attempting to find a way to determine an upstream devices signaling
>    IP from sip messaging.  Let me describe the flow
> 
> Looking at the Contact address in the request probably tells you this.
> 
> But what problem are you attempting to solve?  This mechanism is
> probably not the solution you are seeking.
> 
> Dale
> _______________________________________________

Call flow for nomenclature in the following description.

customer -> switch <-> routing server

I have built a routing server.  I am attempting to implement profit
threshold routing without using "prefixing."  This requires that I am
able to identify who the "customer" is so that I know what the sale
price is to him for a given dialcode.

I can "easily" do this with prefixing on the switch, so that the routing
server could identify who originated traffic. I wanted to try to find a
solution that does not use prefixing, and being able to get the
signaling ip 1 hop upstream from the switch would identify the customer.

The contact uri contains the signaling ip of the switch.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Scott Lawrence | 5 Aug 2008 14:15

Re: Determin upstream signaling device


On Tue, 2008-08-05 at 07:57 -0400, Eric Tamme wrote:

> Call flow for nomenclature in the following description.
> 
> customer -> switch <-> routing server
> 
> I have built a routing server.  I am attempting to implement profit
> threshold routing without using "prefixing."  This requires that I am
> able to identify who the "customer" is so that I know what the sale
> price is to him for a given dialcode.
> 
> I can "easily" do this with prefixing on the switch, so that the routing
> server could identify who originated traffic. I wanted to try to find a
> solution that does not use prefixing, and being able to get the
> signaling ip 1 hop upstream from the switch would identify the customer.
> 
> The contact uri contains the signaling ip of the switch.
> 
> The only thing i have found is the SDP protocol connection information
> contains the customer signaling IP when the switch is not routing media.
> 
> This may be a futile effort.. i just thought id throw the idea out on
> this list since if any one would know, it would be here ;)

Why not just challenge the request for authentication and identify the
customer that way?  That's what it is for....

--

-- 
Scott Lawrence  tel:+1.781.229.0533;ext=162 or sip:slawrence <at> pingtel.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rockson Li (zhengyli | 5 Aug 2008 14:32
Picon
Favicon

Replece question on RFC5057

Hi guys,

On RFC5057 sec 6.

Carol accepts Alice's invitation to replace her dialog (invite usage)
with Bob
...
 Bob then ends his invite usages with both Alice and Carol using BYEs.

however, I don't see Carol send BYE to terminate the dialog(invite
usage) with Bob in Figure 5.

And if Carol sent BYE to Bob, Bob would not send BYE to Carol himself in
Figure 5

Regards,
-Rockson
Permalink | Reply | 0 comments |

Gmane