Although ACK is not a part of INVITE transaction, but I think it must have
same dialog-id as INVITE transaction.
So To-Tag, From-Tag & Call-ID MUST be same as 200OK/180Ringing to INVITE.
Thanks,
Dinesh
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of su
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 gene
From: "Raj Jain" <[EMAIL PROTECTED]>
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 treated tha
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 trea
[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 i
From: "Aneesh Naik" <[EMAIL PROTECTED]>
What should be the behavior when SDP is longer than that given in
"Content-Length" header?
If the SIP message arrives in a UDP datagram, or via some other
protocol which "frames" each message, as you say, the excess bytes
must be discarded.
The
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 de
Yong Xin wrote:
> According to RFC 3261 and 3263, the UAS will send response over UDP if
> received request is over UDP. What if the response is larger than 64K?
[...]
> It seems there's nothing UAS can do other than drop the large response.
> However, UAC may be able to do something:
>
> (1) UAC
Hi,
According to RFC 3261 and 3263, the UAS will send response over UDP if
received request is over UDP. What if the response is larger than 64K?
For example, the F6 (200 response to the SIP INFO) message in the
following SIP call flow is larger than 64K, and F5 (SIP INFO) was sent
by UAC over UD
From: "Amit P. Ahuja" <[EMAIL PROTECTED]>
One of the SIP hardphones that I use sends out a REGISTER message with the
Contact header that looks like:
Contact: sip:[EMAIL PROTECTED]:5060;methods="INVITE, ACK, BYE, CANCEL,
OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, RE
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 imple
Answering both of you... YES.
The offer/answer in the reinvite results in modification of the session
*if* the reinvite is successful. If the reinvite fails then the old
session parameters remain unchanged.
The change can be the addition of streams, removal (rejection) of
streams, modificati
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 gi
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
Subj
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 bey
Hi Daniel,
Please refer the beginning of the section 17 of 3261. It says
"
In the case of a transaction where the request was an INVITE (known as an
INVITE transaction), the transaction also includes the ACK only if the final
response was not a 2xx response. If the response was a
>>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,
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
18 matches
Mail list logo
