Subject: [Sip] BranchID in CANCEL & INVITE

From: Sachin Shenoy <[email-masked]>
Date: Thu, 19 Sep 2002 15:16:10 +0530

Hi,
This is regarding branches in CANCEL & INVITE.

Section 9.1 of RFC says

"9.1 Client Behavior
...
The CANCEL request MUST NOT contain any Require or Proxy-Require header 
fields."

Consider the following scenario
UAC sends INVITE to P1.
P1 forwards it statlessley to UAS.
UAC sends CANCEL to P1 (to cancel the INVITE).
P1 forwards CANCEL also to UAS.

Let INVITE request have Proxy-Require header.

While handling INVITE at proxy,
P1 calculates the VIA's loop-detection part using the Proxy-Require header.
(The unique part would be calculated using a combinatronic function.) So the
INVITE's VIA would reflect the contents of the proxy-require header.

While handling CANCEL at proxy,
P1 calculates the VIA's loop-detection part without the Proxy-Require header,
As CANCEL would not have it.

At UAS:
INVITE & CANCEL would have different top-most via branches.

But according to RFC they have to have the same branches for the UAS to
match the CANCEL & INVITE properly.

"9.1 Client Behavior
...
A CANCEL constructed by a client MUST have only a single Via header field
value matching the top Via value in the request being cancelled.  Using the 
same
values for these header fields allows the CANCEL to be matched with the
request it cancels (Section 9.2 indicates how such matching occurs)."

Is it that Stateless proxies are not supposed to do loop-detection?

I thought the idea of having loop-detection part in branch-id was to
allow proxies to detect loop even while being stateless. If only stateful
proxies were to do loop-detection, we wouldn't have required the hash
to be kept in the message at all.

Thanks in advance
Sachin

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Sachin Shenoy" <[email-masked]>
Date: Sat, 21 Sep 2002 20:42:35 +0530

Someone please help me with this.

Thanks
Sachin

---

From: Himanshoo Ks <[email-masked]>
Date: Mon, 23 Sep 2002 08:56:02 +0530

Hi,

This is with reference to the SIP INFO Method defined in RFC2976.
SIP INFO method is used for sending mid call signaling information. The way
information is sent by a UAC to UAS is clear. But I have one basic question:
1. How does the UAC generating this INFO message know that the UAS is
ineterested in knowing that event.
2. Also we have SUBSCRIBE/NOTIFY messages in SIP which can be used to
subscribe for soem information and then report the same. So in what way is
INFO different than these ..
Could somebody please answer these questions ?

regards
Himanshoo

---

From: "Ranjit Avasarala" <[email-masked]>
Date: Wed, 18 Sep 2002 10:10:28 +0530

Hi Himanshoo

SUBSCRIBE / NOTIFY methods are used to register for specific events like
call fowrward, automatic call back , etc.

while INFO method is used to convey mid session information. The INFO method
only provides optioanl extra information. So UAC may not know whether UAS is
interested in the information or not.

Ranjit :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Himanshoo Ks
Sent: Monday, September 23, 2002 8:56 AM
To: [email-masked]; [email-masked]
Subject: [Sip] SIP INFO

Hi,

regards
Himanshoo

---

From: Himanshoo Ks <[email-masked]>
Date: Mon, 23 Sep 2002 10:25:27 +0530

Your mail says that:

"while INFO method is used to convey mid session information. The INFO
method
only provides optioanl extra information. So UAC may not know whether UAS is
interested in the information or not."

If UAS can't tell what information it is interested in, then what is the use
of INFO method...

Also, then how does UAC decide which information to send.

regards
Himanshoo
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ranjit
Avasarala
Sent: Wednesday, September 18, 2002 10:10 AM
To: Himanshoo Ks; [email-masked]; [email-masked]
Subject: RE: [Sip] SIP INFO

Hi Himanshoo

Ranjit :-)

-----Original Message-----

Hi,

regards
Himanshoo

---

From: Prasanna <[email-masked]>
Date: Mon, 23 Sep 2002 13:17:52 +0800

Hi Himanshoo,
	While it is theoritically possible to generate a complete Event framework
of INFO methods, the SUBSCRIBE / NOTIFY methods provide the formal Event
framework for SIP.
	As Ranjit had mentioned, INFO conveys optional extra information and in the
case of INFO, the UAC does not care if the UAS requires it or not.  The
precise difference lies in this point.  In the Event framework, the UAC
(Notifier) caters to what the UAS (Subscriber) requires, while the INFO
mechanism is adhoc.
	As in case of SIP-T like applications, where INFO is used, the UAS may drop
the message totally, while in the case of NOTIFICATIONs it is not expected
to do that, as he requested the notification.
Regards,
Prasanna

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Himanshoo Ks
Sent: Monday, September 23, 2002 12:55 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: [Sip-implementors] RE: [Sip] SIP INFO

Your mail says that:

regards
Himanshoo
-----Original Message-----

Hi Himanshoo

Ranjit :-)

-----Original Message-----

Hi,

regards
Himanshoo

_______________________________________________
Sip-implementors mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

---

From: Himanshoo Ks <[email-masked]>
Date: Mon, 23 Sep 2002 10:48:10 +0530

Hi,

I have a question on draft-culpepper-sip-info-event-00.txt:

1. It says that MGCP subtype can be used to indicate the protocol between
MGC and MG and then some MGCP message can be encapsulated to request and
report the events as per MGCP packages. Does this mean that I can send the
complete command line ( I mean whole of RQNT) as message body for the INFO
request. It is needed since I also need to identify the end point where I
want event to be detected.

2. And more importantly, as per the date mentioned ni draft, this draft has
expired on October 2000. Is there some other draft / RFC which is taing care
of there issues ? Should I refer to some other document for finding solution
to this problem.

regards
Himanshoo

---

From: "Ranjit Avasarala" <[email-masked]>
Date: Wed, 18 Sep 2002 11:10:32 +0530

Hi Himanshoo

  if there is any extra info to be conveyed to UAS, then UAC generates INFO
request and sends it to UAS. but if UAS is not interested in the info, then
UAS can respond with "487 Request Cancelled" response.

HTH
Ranjit :-)

-----Original Message-----
From: Himanshoo Ks [mailto:[email-masked]]
Sent: Monday, September 23, 2002 10:25 AM
To: [email-masked]; [email-masked];

Your mail says that:

regards
Himanshoo
-----Original Message-----

Hi Himanshoo

Ranjit :-)

-----Original Message-----

Hi,

regards
Himanshoo

---

From: Prasanna <[email-masked]>
Date: Mon, 23 Sep 2002 13:57:50 +0800

HI Ranjit,
	I do not believe 487 is a suitable response for such a condition.  As such
there is no response that is suitable that is usable in this case, but we
can respond with a 400 response.  But do we even have an agreement that this
is a client error!
Rgds,
Prasanna

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ranjit
Avasarala
Sent: Wednesday, September 18, 2002 1:41 PM
To: Himanshoo Ks; [email-masked]; [email-masked]
Subject: [Sip-implementors] RE: [Sip] SIP INFO

Hi Himanshoo

HTH
Ranjit :-)

-----Original Message-----
From: Himanshoo Ks [mailto:[email-masked]]
Sent: Monday, September 23, 2002 10:25 AM
To: [email-masked]; [email-masked];

Your mail says that:

regards
Himanshoo
-----Original Message-----

Hi Himanshoo

Ranjit :-)

-----Original Message-----

Hi,

regards
Himanshoo

---

From: "Ranjit Avasarala" <[email-masked]>
Date: Wed, 18 Sep 2002 13:43:31 +0530

487 is ok be'se if UAS does not want to accept the INFO request, it will
cancel it. U cannot send 400 Bad Request be'se its not a bad request.

Ranjit :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Prasanna
Sent: Monday, September 23, 2002 11:28 AM
To: [email-masked]; Himanshoo Ks; [email-masked];
[email-masked]
Subject: RE: [Sip-implementors] RE: [Sip] SIP INFO

HI Ranjit,

-----Original Message-----

Hi Himanshoo

HTH
Ranjit :-)

-----Original Message-----
From: Himanshoo Ks [mailto:[email-masked]]
Sent: Monday, September 23, 2002 10:25 AM
To: [email-masked]; [email-masked];

Your mail says that:

regards
Himanshoo
-----Original Message-----

Hi Himanshoo

Ranjit :-)

-----Original Message-----

Hi,

regards
Himanshoo

---

From: Prasanna <[email-masked]>
Date: Mon, 23 Sep 2002 16:26:50 +0800

As such 487 is sent when a cancellation of a request is triggered by the UAC
itself (conditions like CANCEL, expiration of the request), but I do not
believe that this is a UAC triggered cancellation.  I withdraw my suggestion
for a 400, for I am also not convinced if UAC behaves erroneously sending
this request or the server behaves erroneously by not able to understand
this.
Do we have a clarity if this is a client error or a server error?
-Prasanna

-----Original Message-----
From: Ranjit Avasarala [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 4:14 PM
To: Prasanna; Himanshoo Ks; [email-masked];

Ranjit :-)

-----Original Message-----

HI Ranjit,

-----Original Message-----

Hi Himanshoo

HTH
Ranjit :-)

-----Original Message-----
From: Himanshoo Ks [mailto:[email-masked]]
Sent: Monday, September 23, 2002 10:25 AM
To: [email-masked]; [email-masked];

Your mail says that:

regards
Himanshoo
-----Original Message-----

Hi Himanshoo

Ranjit :-)

-----Original Message-----

Hi,

regards
Himanshoo

---

From: Himanshoo Ks <[email-masked]>
Date: Mon, 23 Sep 2002 13:42:14 +0530

Hi ,

After reading all of your mails I looked at some of the drafts which are
related to carrying MGCP events  / messages inside SIP INFO Message. If I
follow that approach then it appears that I can first send an INFO request
and include 'MGCP Requested Events' to request detection of events. Later
when that event is deteted, the detectng entitiy will send another INFO
Request with 'MGCP observed events' . By using this approach I can control
the events which are reported to the requestign entity.
This is one use of the INFO message which seems to be very useful.

Regards
Himanshoo

---

From: "Ranjit Avasarala" <[email-masked]>
Date: Wed, 18 Sep 2002 14:33:44 +0530

it is neither a clinet nor server error, but UAS sends 487 indicating to UAC
that it is not interested in accepting the request.

Ranjit :-)

-----Original Message-----
From: Ranjit Avasarala [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 4:14 PM
To: Prasanna; Himanshoo Ks; [email-masked];

Ranjit :-)

-----Original Message-----

HI Ranjit,

-----Original Message-----

Hi Himanshoo

HTH
Ranjit :-)

-----Original Message-----
From: Himanshoo Ks [mailto:[email-masked]]
Sent: Monday, September 23, 2002 10:25 AM
To: [email-masked]; [email-masked];

Your mail says that:

regards
Himanshoo
-----Original Message-----

Hi Himanshoo

Ranjit :-)

-----Original Message-----

Hi,

regards
Himanshoo

---

From: Bert Culpepper <[email-masked]>
Date: Mon, 23 Sep 2002 10:42:01 -0400

Hi,

As you noted, that I-D is expired.  In addition, work is being done to 
define a general mechanism for conveying user indications to support 
user interaction with applications.  The current I-Ds are:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-markup-00.txt
http://www.ietf.org/internet-drafts/draft-culpepper-sipping-app-interact-reqs-01.txt
http://www.ietf.org/internet-drafts/draft-fairlie-sipping-netapp-session-00.txt
http://www.ietf.org/internet-drafts/draft-culpepper-sip-key-events-01.txt

You can expect an update to the requirements I-D shortly I believe.  And 
a general framework, to follow.

> want event to be detected.

The idea was that the the call identifying info in the SIP request would 
be used by the MGC to identify MGCP/Megaco connection.  Just as it would 
for any other interworking function.  The only proposed INFO message 
content was the actual event request/notification.

> of there issues ? Should I refer to some other document for finding solution

Yes, the forthcoming I-Ds mentioned above.

Best Regards,
Bert Culpepper

---

From: "Sharad Goklani" <[email-masked]>
Date: Mon, 23 Sep 2002 15:00:43 +0530

But can't this be done using SUBSCRIBE/NOTIFY ?
Sharad

-----Original Message-----
Sent: Monday, September 23, 2002 1:42 PM

Hi ,

Regards
Himanshoo

---

From: "Sharad Goklani" <[email-masked]>
Date: Mon, 23 Sep 2002 14:59:32 +0530

Actually 487 does not seem to be a correct response to INFO ...
When the originator of the INFO wishes to cancel the INFO sent, it sends a
CANCEL, and 487 can only be sent in response to this CANCEL request.

Per RFC 2976, sec. 2.2:
      A 200 OK response MUST be sent by a UAS for an INFO request with
      no message body if the INFO request was successfully received for
      an existing call.  Beyond that, no additional operations are
      required.
and
      If a server receives an INFO request with a body it understands,
      but it has no knowledge of INFO associated processing rules for
      the body, the body MAY be rendered and displayed to the user. The
      INFO is responded to with a 200 OK.

      If the INFO request contains a body that the server does not
      understand then, in the absence of INFO associated processing
      rules for the body, the server MUST respond with a 415 Unsupported
      Media Type message.

From the above, it seems to mean that:
1. If the (SIP) request is syntactically incorrect,
   it sends a 400
2. If it is syntactically correct, but doesn't understand the (SDP) body,
   it sends 415
3. If it is syntactically correct, and it also understands the body,
   but does not implement the processing rules for the request,
   it sends a 200

Apart from the above, I guess only 481 and 501 are other possible responses.

Hence, if the sender of INFO receives a 200, it has no way of knowing
whether the other end has actually processed the request or has ignored the
same.

Sharad

-----Original Message-----
Sent: Wednesday, September 18, 2002 2:34 PM

Ranjit :-)

-----Original Message-----
From: Ranjit Avasarala [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 4:14 PM
To: Prasanna; Himanshoo Ks; [email-masked];

Ranjit :-)

-----Original Message-----

HI Ranjit,

-----Original Message-----

Hi Himanshoo

HTH
Ranjit :-)

-----Original Message-----
From: Himanshoo Ks [mailto:[email-masked]]
Sent: Monday, September 23, 2002 10:25 AM
To: [email-masked]; [email-masked];

Your mail says that:

regards
Himanshoo
-----Original Message-----

Hi Himanshoo

Ranjit :-)

-----Original Message-----

Hi,

regards
Himanshoo

---

From: Himanshoo <[email-masked]>
Date: Tue, 24 Sep 2002 08:02:58 +0530

> content was the actual event request/notification.

As per your mail , it says :
"The only proposed INFO message content was the actual event
request/notification."
Does this mean (a part of or full ) event request / notification message ,
as per MGCP ?

Best Regards
Himanshoo

---

From: "Ranjit Avasarala" <[email-masked]>
Date: Tue, 24 Sep 2002 10:02:02 +0530

u cannot use SUBSCRIBE/NOTIFY be'se you get NOTIFY when there is a change in
the state of the subscription. but here the case is of event detection. so
as Himanshoo says INFO could be useful

Ranjit :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sharad
Goklani
Sent: Monday, September 23, 2002 3:01 PM
To: 'Himanshoo Ks'; [email-masked]; [email-masked]
Subject: RE: [Sip-implementors] RE: [Sip] SIP INFO

-----Original Message-----

Hi ,

Regards
Himanshoo

---

From: Himanshoo <[email-masked]>
Date: Tue, 24 Sep 2002 10:20:55 +0530

Hi,

I have certain questions related to the scenario explained below. In
addition to the questions, can somebody please also comment if my
understanding is correct:

SCENARIO
-------------
Caller first dials a service access number and therefore call is given to
the App Server by switch :

Caller --(INVITE)--> Switch--(INVITE)--> App Server

After this App Server Invites Media Server into the call and collects the
destination number to which caller wants to talk to .

After getting the destination number , App Server would request the switch
to connect caller to destination number . But Application Server would
always like to monitor the call progress (e.g. is and when call was
answered/terminated/media characteristics changed). So finally it will be
like this:

                    App Server

                         ^
                         | (Monitoring Link)

Caller----> Switch ----->Destination

App server acts as controller . After playing the prompt to user, it
collects digits from user and then it has to connect caller to the called
party. Now I donot want the to develop a module on App Server, which
connects two parties in a call, because softswitch already knows how to do
it.. SO I use REFER (with refer-to field = Destination Number) to ask switch
to connect caller to the destination number, and automatically I am
subscriber for progress of the INVITE which is used to INVITE the
destination number . In additon I need the following:

1. Capability to do Remote Hang UP : My controller should be able to
terminate call to the destination if the call duration exceeds 'allowed
time'. Can I do this using 'REFER ;method = BYE' ?
2. After initiating the dialog using 'REFER; method = INVITE', I also need
to know the progress of dialog. For example if either of caller and called
party hangsup, I need to stop billing. In other words, I want to subscribe
for the state of dialogs involving softswitch and Calling/Called Party.
First I want to know whether I can do this by sending a SUBSCRIBE , using
dialog package 'draft-ietf-sipping-dialog-package-00.txt'?
Also, I want to know whether the dailog state information as per
'draft-ietf-sipping-dialog-package-00.txt' can also notify me of changes in
media characteristics (i.e. SDP for the dialog).?
3. Further in another scenario, if the time allowed for the calling user
(i.e. pre-paid user) expires, and if I want to connect hm to a Media Server
for playing some prompt (to decide future course of action) , then can I do
this by sending 'REFER ; method = BYE for the dialog between softswitch and
called party' and then send 'REFER; method=INVITE for connecting to MRS; In
this case if I want to tell MRS to send the digits to APP server, instead of
switch , how do I do that?

Best Regards
Himanshoo

---

From: Himanshoo <[email-masked]>
Date: Wed, 25 Sep 2002 08:22:59 +0530

Hi All,

This is with reference to the mail I wrote yesterday. Kindly read the
scenario explained below and please comment on my understanding / questions.
Also, let me ask my main question again , with reference to
'draft-ietf-sipping-dialog-package-00':

Following is quoted from the above mentioned package :

 ------------------------
Abstract

    This document defines a dialog event package for the SIP Events
architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another user, and
receive notifications about the changes in state of INVITE initiated dialogs
that the user is involved in.

------------------------

Can I use this package to receive notification for INVITE initiated dialogs
that the initiator is not invo,ved in ( by using "REFER; method = INVITE") ?

If not this way then is there some other way , using SIP, in which a
controller(e.g. App Server) is allowed to have monitoring session with a
switching entity (softswitch) for calls which are actually maintained by the
switch but are also monitored for call processing events by the App Server ?

Kindly do comment...

regards

Himanshoo

----- Original Message -----
From: "Himanshoo" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 24, 2002 10:20 AM
Subject: [Sip] certain questions on third party call control ...

> sip mailing list
> [email-masked]
> To unsubscribe, please go to http://www.vovida.org/mailman/listinfo/sip

---

From: "Sharad Goklani" <[email-masked]>
Date: Tue, 24 Sep 2002 10:19:09 +0530

Cool ... Got it!
Sharad

-----Original Message-----
From: Ranjit Avasarala [mailto:[email-masked]]
Sent: Tuesday, September 24, 2002 10:02 AM
To: [email-masked]; 'Himanshoo Ks'; [email-masked];

Ranjit :-)

-----Original Message-----

Hi ,

Regards
Himanshoo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Sep 2002 02:12:18 -0400

Interesting.

The normative strengths in the specification are correct, but the 
recommended algorithm for performing the branch ID computation for loop 
detection will not work for stateless proxies, as you have identified. 
The algorithm in 16.11 for branch ID computation is stateless proxies is 
correct, but by its definition rules out loop detection using the branch 
ID computation in 16.6.

However, the spec doesn't explicitly point this out, and it should. The 
spec also needs to clarify that the branch ID computation for stateless 
proxies needs to be invariant across retranmits AND CANCEL AND ACK-non-2xx.

I've logged this into bugzilla:
http://www.sipwg.org/sipwg/show_bug.cgi?id=659

Really, loop detection is not something I would recommend. It has caused 
countless problems over the years and thats why max-forwards processing 
is now the preferred approach. So, just turn off loop detection and you 
won't have a problem.

-Jonathan R.

Sachin Shenoy wrote:
> value matching the top Via value in the request being cancelled.  Using 
> the same

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com