Subject: Re: how to distinguish call leg if both From and To are same

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 13 May 1999 15:47:07 -0500

You use the Call-ID to disinguish between the calls traversing the proxy.
>From RFC 2543:

6.12 Call-ID
The Call-ID general-header field uniquely identifies a particular
invitation or all registrations of a particular client.
...
These rules guarantee overall global uniqueness of the Call-ID.

Stephen

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: [email-masked]

-----Original Message-----
From: Anoop Tripathi <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, May 13, 1999 10:00
Subject: how to distinguish call leg if both From and To are same

>
>
>
>On a proxy server ,
>
>if  I happen to have a call which has the same value of  From  & To fields
, how
>do I distinguish the call leg. ( e.g a BYE request )
>
>Thanks,
>
>Anoop Tripathi
>
>3COM
>
>

---

From: John Hearty <[email-masked]>
Date: Fri, 14 May 1999 11:33 -0500 (CDT)

Anoop,

 The BYE request in your example will be as follows if it came from
the calling party:

Callid         : 1234
          To :      [email-masked]
          From :    [email-masked]

 If it came from the called party, it will be:

Callid         : 1234
          To :      [email-masked]
          From :    [email-masked]

 Section 16.4 notes that if the callee wants to abort the call, it
simply reverses the To and From feilds.  This is how you distinguish
who sent the BYE.

John Hearty
MCI Worldcom

Date: Fri, 14 May 1999 09:00 -0500 (CDT)
From: Anoop Tripathi <[email-masked]>
To: Jonathan Rosenberg <[email-masked]>
CC: [email-masked]
Sender: [email-masked]
Subject: Re: how to distinguish call leg if both From and To are same

Assume an SCN to IP interworking Client ( previously a H323 GW now runnning SIP
).

It registers with proxy server(2.2.2.2)  as

[email-masked]

A call arrive on the PRI line for phone number (312)2222222 .

The SIP Client  sends the request to proxy as follows:

Request URI : [email-masked]
Call Id        : 1234
          To :      2.2.2.2
          From :    1.1.1.1

The proxy finds  that  the number is forwarded to (847)3333333.

It sends an INVITE to the same client :

Request URI: (847)3333333:
Callid         : 1234
          To :      2.2.2.2
          From :    1.1.1.1
          Via : 2.2.2.2
Now all other messages are direction sensitive ( e.g. responses and ACKs ).

But what  about the BYE request.

It will always have
Callid         : 1234
          To :      2.2.2.2
          From :    1.1.1.1
          Via : 2.2.2.2

So how do I find out who terminated the call.( It looks like I will have to look
either at the request URI or Via fields to distinguish them .)
Please correct me if I am wrong.

Thanks,

Anoop

Proxy sends

Jonathan Rosenberg <[email-masked]> on 05/13/99 09:03:13 PM

Sent by:  Jonathan Rosenberg <[email-masked]>

To:   Anoop Tripathi/MW/US/3Com
cc:   [email-masked]
Subject:  Re: how to distinguish call leg if both From and To are same

I'm not sure what you mean. Are you asking: If a user calls themself,
the caller and callee are both on the same machine and port. So, when a
message arrives, is it for the caller or callee? Not sure its
particularly useful. In any case, you would know by the tags. The names
may be the same, but in one case the tag will appear in the To field (if
the message is destined for the callee), otherwise the From field (if
for the caller).

-Jonathan R.

Anoop Tripathi wrote:
>
> On a proxy server ,
>
> if  I happen to have a call which has the same value of  From  & To fields ,
how

--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 May 1999 23:33:05 -0400

> It registers with proxy server(2.2.2.2)  as

Well, first off, SIP registrations don't support wildcarding like this.
If you want to establish routing tables for phone calls (which is what
this is) use the Gateway Location Protocol (GLP), not SIP registrations. 

>  The BYE request in your example will be as follows if it came from

The same basic idea is true for your INVITE. It should look like, from
the calling gateway to proxy:

INVITE sip:[email-masked] SIP/2.0
From: sip:<calling number here>@1.1.1.1
To: sip:[email-masked]
.....

and from proxy to terminating gateway (same gateway):

INVITE sip:[email-masked] SIP/2.0
From: sip:<calling number here>@1.1.1.1
To: sip:[email-masked]
.....

Now, if the terminating gateway sends BYE, the To and From are reversed.
If the originating gateway sends BYE, they are the same, as John has
mentioned.

I should also note that since the calling gateway has a destination
number that is a plain phone number, it probably shouldn't append the
2.2.2.2 (which is the proxy address) to get a SIP URI, but rather place
a phone URI in the To field instead of the SIP URI, and then let the
proxy translate the phone URI (phone:3122222222) into a SIP URI
(sip:[email-masked]), which gets place in the Request URI of the
proxied request.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 May 1999 10:42:03 -0400

(Moving this to confctrl where it belongs)

I don't know how you reach this conclusion from 16.3. The flows there
(none of which are for BYE, by the way), all have To and From mirrored
in the responses. Section 16.4 mentions BYE, but has no response in the
example. 

The correct behavior is that the To and From are mirrored in responses,
with the possible addition of a tag in the To field.

-Jonathan R.

Anoop Tripathi wrote:
> 
> RFC 2543 Dated March 1999
> 
> Section 16.3 :
> 
> The message flow shows that for responses the From and To fields are not
> mirrored.
> 
> So , I guess to distinguish a call leg , I always need the tag header.
> 
> Note: This is a problem only for the 200 OK response for a BYE.
> 
> Thanks,
> 
> Anoop
> 
> Jonathan Rosenberg <[email-masked]> on 05/19/99 10:25:33 PM
> 
> cc:   [email-masked]
> Same answer. Based on the To and From fields. The response to any
> request mirrors the To and From, with the possible addition of a tag in
> the To field.
> 
> -Jonathan R.
> 
> Anoop Tripathi wrote:
> >
> > Thanks for clearing my doubt on BYE message call leg finding.
> >
> > Going further on the same question :
> >
> > Now I have one on the 200 Response for a BYE message.
> >
> > On  a proxy,
> >
> > When I get a 200 OK Response for a BYE ,
> >
> > How do I find out which leg of the call sent it.
> >
> > Thanks,
> >
> > Anoop
> >
> > Jonathan Rosenberg <[email-masked]> on 05/14/99 10:33:05 PM
> >
> > cc:   [email-masked]

---

From: "Anoop Tripathi" <[email-masked]>
Date: Thu, 20 May 1999 11:06:51 -0500

Sorry Again. You are right the two OKs will have different from and to fields.

I was reading it wrong.

Anoop.
---------------------- Forwarded by Anoop Tripathi/MW/US/3Com on 05/20/99 11:01
AM ---------------------------

Anoop Tripathi/MW/US/3Com
05/20/99 11:04 AM

Sent by:  Anoop Tripathi   -  Software Engineer, Carrier Systems

To:   Jonathan Rosenberg <[email-masked]> @ 3COM-MWGATE
cc:   [email-masked]@3COM-MWGATE
Subject:  Re: how to distinguish call leg if both From and To are same
      (Document link not converted)

Sorry for confusion.

A BYE  from Originating User Agent will have :

A BYE from terminating User Agent will have :

From: sip:[email-masked]
To: sip:<calling number here>@1.1.1.1

But an OK for both these BYEs will have

So , if I don't use tag header , I cannot distinguish who sent the OK.

Anoop

Jonathan Rosenberg <[email-masked]> on 05/20/99 09:42:03 AM

-Jonathan R.

Anoop Tripathi wrote:
> > > Assume an SCN to IP interworking Client ( previously a H323 GW now
runnning
> > SIP