hi,
well when u get a 200 Ok for Re-Invite with a corrupted SDP then the UA
should send an Ack for the 200 ok and then depending on the local policies
you can -
1.send another Re-Invite with a new offer
2.still continue the media session with the previous successful
negotiation.(Successful Invite)
3.if not interested to continue with on going media session then u can
terminate the session.
And generally you would not get an offer SDP in a 200 Ok for a Re-invite
as the person sending the Re-invite request would be sending the offer and
would not expect the other end to send an offer.
Regards,
Arun Manian
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Friday, November 18, 2005 5:58 PM
To: sip-implementors@cs.columbia.edu
Subject: Sip-implementors Digest, Vol 32, Issue 45
Send Sip-implementors mailing list submissions to
sip-implementors@cs.columbia.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sip-implementors digest..."
Today's Topics:
1. RE: ReInvite with 200 OK corrupted SDP
([EMAIL PROTECTED])
2. Re: Call-ID usage by UA within thesamebootcycle, after a
network failure (Jeroen van Bemmel)
3. To-Tag in INVITE request (Sigrid Thijs)
4. Re: To-Tag in INVITE request (Aswin Bhupalam)
5. CANCEL message construction at proxy level
([EMAIL PROTECTED])
6. RE: To-Tag in INVITE request (Karthik Kamaraj - NPD, Chennai)
7. RE: To-Tag in INVITE request (Manjunath Warad)
8. RE: To-Tag in INVITE request (Anshuman Rawat)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Nov 2005 10:30:37 +0530
From: <[EMAIL PROTECTED]>
Subject: RE: [Sip-implementors] ReInvite with 200 OK corrupted SDP
To: <sip-implementors@cs.columbia.edu>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Hi Niraj,
Interesting question.. In my opinion UAC should ignore the response
message with incorrect body. UAC may ACK this and choose to terminate
the dialog with a BYE.
Scenraio may get more complicated if UAC is expecting offer in 200 OK. I
am not sure how UAC can respond back with a syntactically correct answer
in ACK when it couldn't understand the offer in 200 OK.
I wait for answer from Gurus.
-Ramakrishna
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 6:33 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] ReInvite with 200 OK corrupted SDP
Hi,
What should be the behavior of UA when it receives 200 OK with
corrupted SDP for reInvite
it has sent ?
Regards,
Niraj
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Confidentiality Notice
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 confidential or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
[EMAIL PROTECTED] immediately
and destroy all copies of this message and any attachments.
------------------------------
Message: 2
Date: Fri, 18 Nov 2005 07:23:30 +0100
From: "Jeroen van Bemmel" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] Call-ID usage by UA within
thesamebootcycle, after a network failure
To: "Dale R. Worley" <[EMAIL PROTECTED]>, "Sip-Implementors"
<sip-implementors@cs.columbia.edu>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
> On Thu, 2005-11-17 at 23:47 +0100, Jeroen van Bemmel wrote:
>> Well, it makes a difference in the sense that the element at fault here
>> is
>> the registrar, not the UAs. The registrar should not be implemented based
>> on
>> the assumption that UAs use the same Call-ID (i.e. what you're doing when
>> you segregate based on Call-ID), else you get precisely the kind of
>> cluttered database that you talked about (for UAs that don't honor the
>> SHOULD).
>>
>> The registration database structure should look something like this:
>>
>> AoR --> Contact URI --> BindingInfo (call-id, cseq, expire time, more)
>> 1 : N 1 : 1
>
> Actually, it's
>
> AoR (1:N) Contact URI (1:1) (expire time)
Yes, that's what I intended above (except that per Contact URI more than
just the expire time can be maintained). In my example the last Call-ID and
CSeq seen for that Contact URI are also maintained.
>
> But you need an additional table to track the last-seen CSeq for each
> Call-Id -- If I register a contact using one Call-Id, then refresh it
> using another Call-Id, and then I send a third refresh, which CSeq it
> can use is determined by which Call-Id it uses.
>
The CSeq check only works if the UAC sends the same Call-ID each time. If
the second one it sends is different, there's a good chance that the third
will again be different. So I don't see the point of keeping more than 1
CSeq/Call-ID per UAC Contact (i.e. only the latest pair it sent).
Jeroen
------------------------------
Message: 3
Date: Fri, 18 Nov 2005 12:37:04 +0100
From: Sigrid Thijs <[EMAIL PROTECTED]>
Subject: [Sip-implementors] To-Tag in INVITE request
To: sip-implementors@cs.columbia.edu
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
when a UA receives an INVITE request with a to-tag it should check if
there's a dialog that matches the request. But what if there's no
matching dialog? Should the UA treat it as an in-dialog request and
respond with an 481 (call leg/transaction does not exist) response. Or
should the UA treat it as an out-of-dialog request, create a dialog and
respond with 1xx reponses?
Kind regards,
Sigrid Thijs
------------------------------
Message: 4
Date: Fri, 18 Nov 2005 17:17:35 +0530
From: "Aswin Bhupalam" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] To-Tag in INVITE request
To: "Sigrid Thijs" <[EMAIL PROTECTED]>,
<sip-implementors@cs.columbia.edu>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
Ideally, the UA should reject with 481 (call leg/transaction does not exist)
response.
Some IP phones do this.
But, Pingtel or snom (I dont remember) was little liberal and was treating
the invite with to-tag as new call.
Regards,
Aswin Bhupalam.
----- Original Message -----
From: "Sigrid Thijs" <[EMAIL PROTECTED]>
To: <sip-implementors@cs.columbia.edu>
Sent: Friday, November 18, 2005 5:07 PM
Subject: [Sip-implementors] To-Tag in INVITE request
> Hi,
>
> when a UA receives an INVITE request with a to-tag it should check if
> there's a dialog that matches the request. But what if there's no
> matching dialog? Should the UA treat it as an in-dialog request and
> respond with an 481 (call leg/transaction does not exist) response. Or
> should the UA treat it as an out-of-dialog request, create a dialog and
> respond with 1xx reponses?
>
> Kind regards,
> Sigrid Thijs
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------
Message: 5
Date: Fri, 18 Nov 2005 17:26:18 +0530
From: [EMAIL PROTECTED]
Subject: [Sip-implementors] CANCEL message construction at proxy level
To: Sip-Implementors <sip-implementors@cs.columbia.edu>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi All,
I am new to this mail grpu and SIP world :). I need some information
about how to construct the CANCEL message at the proxy level.
Scenario
1> Caller A sends INVITE message to PROXY
2> PROXY(stateful) send 100 trying to caller A and sends the INVITE
message to caller B
3> Caller A sends CANCEL message to PROXY to cancel the INVITE message
4> PROXY send 200 OK and 487 response back to Caller A and checks for
1xx response from caller B and construct the CANCEL message to send to
caller B
5> PROXY construct this message with same Request-URI, TO , FROM,
CALL-ID and Cseq number field values of the INVITE message send to
caller B and insert it own VIA header field value. the branch id is
different from the one which is sent in INVITE message to caller B.
5> But the CALLER B sends 481 Call/Transaction Does Not Exist message
back to PROXY.
NOTE: if the CALLER B is CISCO media gateway, then it accept CANCEL
message by sending 200 OK and 487 message, But if it is a Pingtel phone
then it sends 481.
Any clue why the behavior is different here.
Thanks and Regards
-venkat
------------------------------
Message: 6
Date: Fri, 18 Nov 2005 17:39:33 +0530
From: "Karthik Kamaraj - NPD, Chennai" <[EMAIL PROTECTED]>
Subject: RE: [Sip-implementors] To-Tag in INVITE request
To: "Sigrid Thijs" <[EMAIL PROTECTED]>,
<sip-implementors@cs.columbia.edu>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Sigrid,
If UA receives the request with to tag than it MUST use the same
tag in the response.See section 8.2.6.2 in RFC 3261.
"If a request contained a To tag in the request, the To header field
in the response MUST equal that of the request. However, if the To
header field in the request did not contain a tag, the URI in the To
header field in the response MUST equal the URI in the To header
field; additionally, the UAS MUST add a tag to the To header field in
the response (with the exception of the 100 (Trying) response, in
which a tag MAY be present)"
Thanks,
Karthik
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Sigrid
Thijs
Sent: Friday, November 18, 2005 5:07 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] To-Tag in INVITE request
Hi,
when a UA receives an INVITE request with a to-tag it should check if
there's a dialog that matches the request. But what if there's no
matching dialog? Should the UA treat it as an in-dialog request and
respond with an 481 (call leg/transaction does not exist) response. Or
should the UA treat it as an out-of-dialog request, create a dialog and
respond with 1xx reponses?
Kind regards,
Sigrid Thijs
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Disclaimer:
This message and any attachment(s) contained here are information that is
confidential, proprietary to HCL Technologies and its customers, privileged
or otherwise protected by law. The information is solely intended for the
individual or the entity it is addressed to. If you are not the intended
recipient of this message, you are not authorized to read, forward, print,
retain, copy or disseminate this message or any part of it. If you have
received this e-mail in error, please notify the sender immediately by
return e-mail and delete it from your computer.
------------------------------
Message: 7
Date: Fri, 18 Nov 2005 17:43:53 +0530
From: Manjunath Warad <[EMAIL PROTECTED]>
Subject: RE: [Sip-implementors] To-Tag in INVITE request
To: "'Sigrid Thijs'" <[EMAIL PROTECTED]>,
sip-implementors@cs.columbia.edu
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Hi,
This condition can occur, if the UAS might have crashed or restarted
for some reason. Its implementation dependent, either accept or reject this
request. Can be rejected as you said with 481 (call leg/transaction does not
exist) response, if accepted then UAS should be in a position to construct
route set and other required information.
For further details you can refer,
RFC 3261, Sec 12.2.2
If the request has a tag in the To header field, but the dialog
identifier does not match any existing dialogs, the UAS may have
crashed and restarted, or it may have received a request for a
different (possibly failed) UAS (the UASs can construct the To tags
so that a UAS can identify that the tag was for a UAS for which it is
providing recovery). Another possibility is that the incoming
request has been simply misrouted. Based on the To tag, the UAS MAY
either accept or reject the request. Accepting the request for
acceptable To tags provides robustness, so that dialogs can persist
even through crashes. UAs wishing to support this capability must
take into consideration some issues such as choosing monotonically
increasing CSeq sequence numbers even across reboots, reconstructing
the route set, and accepting out-of-range RTP timestamps and sequence
numbers.
If the UAS wishes to reject the request because it does not wish to
recreate the dialog, it MUST respond to the request with a 481
(Call/Transaction Does Not Exist) status code and pass that to the
server transaction.
Regards,
Manju
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sigrid Thijs
Sent: Friday, November 18, 2005 5:07 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] To-Tag in INVITE request
Hi,
when a UA receives an INVITE request with a to-tag it should check if
there's a dialog that matches the request. But what if there's no
matching dialog? Should the UA treat it as an in-dialog request and
respond with an 481 (call leg/transaction does not exist) response. Or
should the UA treat it as an out-of-dialog request, create a dialog and
respond with 1xx reponses?
Kind regards,
Sigrid Thijs
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------
Message: 8
Date: Fri, 18 Nov 2005 17:55:58 +0530
From: "Anshuman Rawat" <[EMAIL PROTECTED]>
Subject: RE: [Sip-implementors] To-Tag in INVITE request
To: "Sigrid Thijs" <[EMAIL PROTECTED]>,
<sip-implementors@cs.columbia.edu>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Sigrid,
Both are legally possible. The final result will depend on what you
actually want. Please refer to sections 13.3.1 (point 3) and 12.2.2 in
RFC 3261.
Regards,
Anshuman S. Rawat
Software Group,
Conexant Systems India Private Ltd.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sigrid
Thijs
Sent: Friday, November 18, 2005 5:07 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] To-Tag in INVITE request
Hi,
when a UA receives an INVITE request with a to-tag it should check if
there's a dialog that matches the request. But what if there's no
matching dialog? Should the UA treat it as an in-dialog request and
respond with an 481 (call leg/transaction does not exist) response. Or
should the UA treat it as an out-of-dialog request, create a dialog and
respond with 1xx reponses?
Kind regards,
Sigrid Thijs
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole
use of the intended recipient. Any unauthorized review, use or distribution
by others is strictly prohibited. If you have received the message in
error, please advise the sender by reply email and delete the message. Thank
you."
**********************************************************************
------------------------------
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
End of Sip-implementors Digest, Vol 32, Issue 45
************************************************
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 confidential or privileged information. If you are not the intended
recipient, please notify the sender or [EMAIL PROTECTED]
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
