Manoj Priyankara [TG] wrote:
> Dear All,
>
> When an INVITE passes through a SIP proxy, should the contact header
> change?
>
> Thanks
> BR,
> Manoj
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columb
Dear All,
When an INVITE passes through a SIP proxy, should the contact header
change?
Thanks
BR,
Manoj
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
T Satyanarayana-A12694 wrote:
> Yes, I do agree that implementations have done a good job of working
> with this ambiguity so far. And, it is not as much an issue.
>
> However, I am having a difficulty to visualize a use case where the
> offerer may use this "addl codec" to send media. Even if t
The bullet applies to the called party (not the calling party). As mentioned
elsewhere within rfc3261, the caller can send BYE over early dialog.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Beh
That's great Uttam Da,
Raikkme:
A UA compliant to RFC-3261 can not send BYE on early dialog as pointed
by Uttam. But rfc3261 does allow for handling the calls from devices
compatible with prior specification rfc-2543. So could you clarify
whether your UA-A and UA-B are not compliant to RFC-3261
As per page 258 of RFC 3261(28.1 Major Functional Changes)
o A UA cannot send a BYE for a call until it has received an ACK for
the initial INVITE. This was allowed in RFC 2543 but leads to a
potential race condition.
-Original Message-
From: Singh, Indresh (NSN - US/B
Uttam Da,
As per Section 15 Terminating a session Pg 89
A caller's UA MAY send a BYE for either confirmed or early dialogs and
the callee's UA MAY send a BYE on confirmed dialogs, but MUST not send a
BYE on early dialogs.
In our implementations we normally send CANCEL on the early dialogs, but
a
You will not be able to send BYE as call is not yet connected.
You can send CANCEL to the INVITE.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Singh, Indresh (NSN - US/Boca Raton)
Sent: Tuesday,
Assuming that your call-flow is like
UA-A B2BUA
UA-B
INVITE >
INVITE->
180
without contact <--
180 with contact<-
Hi Indresh,
Just one small clarification. As the entity behaves as B2B, 18x is sent
towards A side with contact header(B2B's address), after receiving 18x
without contact header from B side.
Query is that, how the release from A side(as indicated in the picture) to
be treated? Or 18x from A side,
Sorry, I meant "Even if the answerer is prepared to receive"..
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of T
Satyanarayana-A12694
Sent: Tuesday, August 18, 2009 11:07 PM
To: Paul Kyzivat
Cc: s
Yes, I do agree that implementations have done a good job of working
with this ambiguity so far. And, it is not as much an issue.
However, I am having a difficulty to visualize a use case where the
offerer may use this "addl codec" to send media. Even if the offerer is
prepared to receive, the of
Interesting,
That means that again that either Table-2 has made contact header
optional because section 12.1 + 12.1.1 is applicable for 101-199 ( not
100 trying ), but the table covers 100-199.
It would make sense to have contact header in 18x responses where
subsequent method have to be sent ou
> But as Vikram pointed out that contact header is an optional header
> in 1xx responses.
The example indicates that the 18x with To tag (and without Contact) was the
dialog forming response. Thus the Contact header is not optional.
The following are two rfc3261 snippets which indicate that t
Still the figure is not very clear.
But as Vikram pointed out that contact header is an optional header in
1xx responses. If no contact header is present in 1xx response then if a
method has to be sent out immediately after this 1xx response ( prior to
receiving another response with contact heade
soma bhargava wrote:
> Hi All,
>
> As per RFC 3261
> sec 8.2.2.3 Require:
> An ACK request for a 2xx response MUST contain only those Require
> and Proxy-Require values that were present in the initial request.
I think that is less than ideal wording.
It would have been better worded as:
"An A
> 18x from B side received without contact header.
> 18x response has "To tag" and without Record Route.
Per RFC 3261 section 12.1, the To tag within 101-299 response (to dialog
creating request) creates the dialog. If the required Contact is missing, it
is a malformed message. Since malforme
The more I think about this "issue" the less I understand why it should
be an issue.
The answerer is under no obligation to include codecs that were not
present in the offer. And if it does so, there is no guarantee of
circumstances under which they might be used. And the offerer is
certainly
Shyam,
I think that require header in ACK for 200 OK should not be included (
as indicated by the Table-2 of RFC-3261, as it has '-' which implies not
applicable, which is furthur clarified as meaning that the header field
MUST not be present in a request ).
Now going by the section 8.2.2.3 state
I tried to translate the picture in notepad. I hope, it is received as
intended. Please find below.
A
side
B side
__
-> | B |
Invite |
|---> Invite
Hi,
Require 100REL in ACK does not have any meaning.
Require Header with other parameters like timer.. or any user defined
parameters may be present.
Thanks,
Shyam
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia
Hi All,
As per RFC 3261
sec 8.2.2.3 Require:
An ACK request for a 2xx response MUST contain only those Require
and Proxy-Require values that were present in the initial request.
and as per section 20 of RFC3261:
Header field where proxy ACK BYE CAN INV OPT REG
Require ar - c -
22 matches
Mail list logo
