If 200 OK of INVITE is bad, then you may choose not to send ACK.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sarju
Garg
Sent: Tuesday, June 13, 2006 1:02 AM
To: SIP Implementors (E-mail)
Subject: [Sip-implementors] Query Regarding Handling of Bad 200 Ok
message
Hi all,
I would request someone to let me know what should be the handling in
case UAC receives a bad 200 Ok message. For example, in case SDP format
is not ok.
Thanks in advance
Regards
Sarju
# 9810304396
----- Original Message -----
From: Rayees Khan
To: Stephen Paterson
Cc: SIP Implementors (E-mail)
Sent: Monday, June 12, 2006 11:57 PM
Subject: Re: [Sip-implementors] Session timer - how to indicate the
session hasnot changed
Hi Stephen,
This is a protocol violation, however, the handling of such things is
highly local to the Endpoint. An EP can choose to just check the o-line
and decide on the basis of this whether to process rest of SDP or not.
regards
Rayees
[EMAIL PROTECTED] wrote: -----
To: "SIP Implementors (E-mail)" <[email protected]>
From: Stephen Paterson <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
Date: 06/12/2006 11:31AM
Subject: [Sip-implementors] Session timer - how to indicate the
session hasnot changed
Hi all,
The last paragraph of section 7.4 of RFC 4028 states:
'It is RECOMMENDED that the UPDATE request not contain an offer [4],
but a
re-INVITE SHOULD contain one, even if the details of the session
have not
changed. In that case, the offer MUST indicate that it has not
changed. In
the case of SDP, this is accomplished by including the same value
for the
origin field as did previous SDP messages to its peer. The same is
true for
an answer exchanged as a result of a session refresh request; if it
has not
changed, that MUST be indicated.'
What happens when the refresher sends an offer with an unchanged
origin
field, receives a 200 OK with an unchanged origin field but an 'm='
line
that was present in the most recent offer/answer exchange is missing
from
the UAS response?
My gut feeling is that the UAS is out of spec (and the entire SDP
should be
unchanged) but according to the quote above, only the origin field
needs to
be unchanged in order to indicate that the session details are also
unchanged.
At the moment this causes problem for our SIP implementation as it
has no
control over the media. It simply raises an event to the application
that is
controlling the media to indicate that the session parameters have
changed.
We don't want to be doing this for session refresh requests unless a
genuine
offer/answer exchange has been negotiated during the transaction.
If the UAS is out of spec, how should the UAC behave?
If not, is there anywhere in the RFCs that specifies more clearly
how to
identify that a media session is unchanged? I haven't been able to
find
anything in SIP, SDP, Session Timer or Offer Answer (which isn't to
say the
answers aren't there somewhere).
It may well be the case that I just have to change our logic and
ignore all
of the SDP if the 'o=' is unchanged. Part of my query is to ensure
that, if
I do this, I don't break anything elsewhere.
Cheers
Steve
Steve Paterson
Software Engineer
Aculab
Tel: +44 (0) 1908 273866
Fax: +44 (0) 1908 273801
Email: mailto:[EMAIL PROTECTED]
Website: http://www.aculab.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
*****FSS-Private *****" DISCLAIMER: This message is proprietary to
Flextronics Software Systems Limited (FSS) and is intended solely for
the use of the individual to whom it is addressed. It may contain
privileged or confidential information and should not be circulated or
used for any purpose other than for what it is intended. If you have
received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified
that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. FSS accepts no responsibility
for loss or damage arising from the use of the information transmitted
by this email including damage from virus."
------------------------------------------------------------------------
------
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
