Hi,
when an INVITE client transaction is in the Calling state and proceeding state,
on receipt of Success (200 OK) responses. Is ACK should send same as received
To_Tag of To_Tag on ACK(sent)?
Any help is appericated.
Thanks
Sudhir
Save all your chat conversations. Find them online
Once a transaction has been destroyed, shouldn't the UAS respond to
the ACK with a 481? Or should it just silently absorb the ACK?
Never send a response to an ACK request.
The ACK request is a special request that has no response.
ACK should always be silently absorbed.
Regards,
Attila
Hi,
What should be the behavior when SDP is longer than that given in
Content-Length header?
The RFC 3261 section 18.3 Framing states:
If there are additional bytes in the transport packet beyond the end of the
body, they MUST be discarded.
So this means, SIP parser should discard the data
Discard the extra bytes. You have no choice.
And tell the UA vendor to fix their implementation.
Regards,
Attila
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Aneesh Naik
Sent: 20 December 2007 12:03
To: Sip-implementors@lists.cs.columbia.edu
Comments Inline...
Regards,
Nataraju A B
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Aneesh Naik
Sent: Thursday, December 20, 2007 5:33 PM
To: Sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SDP longer than that given in
Do the spaces matter for SIP messages or their contents? According to
3840, the definitions for the methods= Feature Tag are in compliance
with RFC2730, which specifies both textual and non-textual (ASN.1
encoded) representations for negotiating capabilities. I would be
surprised if a SIP
From: Harsha. R [EMAIL PROTECTED]
If a UAC makes an SDP offer in RE-INVITE, can the offer be rejected
in a 200 OK?
No, of necessity, the SDP in a 200 OK is an SDP answer (if the INVITE
contained an offer), and that SDP takes effect in the dialog.
*However*, the SDP might include a
[EMAIL PROTECTED] wrote:
Searching for methods in RFC 3840 turns up an oddity: Section 5
says:
When using the sip.methods feature tag, a UA MUST NOT include
values that correspond to methods not standardized in IETF standards
track RFCs.
but two paragraphs later it says:
Interesting. I though the answer to that question was YES.
But, I can understand Dale's response. So, you can accept an SDP offer (by
sending back a 200 instead of a 488), while you may reject every media
stream in the offer (by setting each m= line port equals to 0 in the
answer). I'd have
Hi All,
when an INVITE client transaction is in the Calling state, on receipt
of Success (200 OK) response. As per RFC 17.1.1.2(Figure 5: INVITE
client transaction), the 2xx response MUST cause the client transaction
to enter the Terminated state. But, I'm not sure what would be To_Tag
in
10 matches
Mail list logo
