pposed to know that it is
>> not OK now? If that is the case, then the Allow header is useless.
>>
>> It just does not make sense.
>>
>>
>> cheers,
>> (-:bob
>>
>>
>>
>>
>> -Original Message-
>> From: Brett Tate [mail
In that case the change can be communicated in the signaling be having UPDATE
absent from the Allow header in the 200-OK and/or ACK. My point is that if the
most recent signaling message (INVITE and/or 18x) included UPDATE in the allow
header, then the other end ought to be able to send UPDATE w
just does not make sense.
cheers,
(-:bob
-Original Message-
From: Brett Tate [mailto:br...@broadsoft.com]
Sent: Wednesday, March 21, 2012 8:52 AM
To: Bob Penfield; Kashif Husain; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] 405 response for UPDATE
If UPDATE was
Then does that mean the RFC 5057 is incorrect when it says:
(3) 405 Method Not Allowed:
501 Not Implemented:
Either of these responses would be aberrant in our example
scenario since support for the NOTIFY method is required by the
usage. In this case, the UA knows t
No, it is not valid behavior. The Allow header should contain only methods that
are "allowed" and supported by the UA. It is particularly problematic when you
consider that RFC 5057 indicates that a 405 response destroys the INVITE usage.
cheers,
(-:bob
-Original Message-
From: sip-i
It may just be part of your implementation, but Transactions are independent of
dialogs. There is nothing in RFC 3261 that associates transactions and dialogs
together in a way that the state of the dialog would affect the state of a
pending transaction.
The main point is that the reception of
Text with normative language (i.e. MUST, SHOULD, RECOMMENED, etc. from RFC
2119) always takes precedence. Therefore the "MUST" in section 12.1.1 applies
when the 1xx creates a dialog. Table 2 should have "c" for Contact in 1XX
responses. Maybe we should file an errata.
cheers,
(-:bob
-O
A BYE will terminate a specific dialog. A CANCEL is intended to cancel all
branches (all early dialogs) of a potentially forked INVITE. If an INVITE was
forked by a forking proxy, the CANCEL is sent on all branches of the fork.
Sending BYE on an early dialog can be used to cancel/terminate a sin
: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Friday, June 10, 2011 8:35 AM
To: Bob Penfield
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] About CANCEL in a proxy (no
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Thursday, June 09, 2011 7:15 PM
To: Bob Penfield
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] About CANCEL in a proxy (
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Thursday, June 09, 2011 5:33 PM
To: Bob Penfield
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] About CANCEL in a proxy (no changes to
server/client transaction)
2011/5/11 Bob Penfield :
>
You have it correct. The proxy's job is to pass the CANCEL on each branch of
the matching transaction. The basic rule of SIP is that all transactions
complete independently. The state of the transactions is dependant only on the
response(s) for the request and the timers on the transactions. The
umbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Tuesday, May 10, 2011 9:10 AM
To: Bob Penfield
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Proxy receives 200 for INVITE while in
"completed" state
2011/5/10 Bob Penfield :
> In RFC 3261, section 16.7 (Re
In RFC 3261, section 16.7 (Response Processing for proxies) on page 110, it
says:
After a final response has been sent on the server transaction,
the following responses MUST be forwarded immediately:
- Any 2xx response to an INVITE request
Thus the proxy must forwar
The URI host name is case-insensitive. ATLANTA.COM and atlanta.com are the same
host.
>From RFC 3261:
Comparison of the userinfo of SIP and SIPS URIs is case-
sensitive. This includes userinfo containing passwords or
formatted as telephone-subscribers. Comparison of all other
You cannot use scenario 4 and scenario 2 in the same INVITE. Scenario 2 can
only be used as the initial offer/answer (for a new session) or for an
established session (i.e. a re-INVITE). There can be only one offer/answer in a
single INVITE transaction. There can be a second offer/answer exchang
Since the RFC says the disallowed component (the port) should be ignored, then
the port should not be included in AOR comparisons.
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Tuesday, December 28, 2010 4:40 PM
To: Bob Penfield
Cc: sungwoo1769
Actually, according to Table 1 on page 152 of RFC 3261, the port is not legal
for a From or To header. The From and To headers are Identities or Addresses of
Records and not targetable SIP URIs. The port should be omitted in From and To
headers.
However, the presence of a port in the From or To
You have it backwards. SDP describes what a User Agent is prepared to received.
Therefore, when A offers 96 for DTMF, B must send DTMF using payload 96. When B
answers with 101 for DTMF, A must send DTMF using payload 101.
-Original Message-
From: sip-implementors-boun...@lists.cs.columb
First, the branch id that the UAC is using does not begin with the magic branch
cookie "z9hG4bK". This will cause the UAS to believe that the UAC is NOT
conformant to RFC 3261 and may be contributing to the failure to match the ACK.
According to section 8.1.1.7 of RFC 3261:
The branch ID inse
I believe the 200-OK in the flow is the 200-OK to the PRACK, not the INVITE.
The Calling UA should be able to handle multiple reliable provisional responses
and send a PRACK for them especially in the case where the previous one was
PRACK'd and the PRACK got a success response.
cheers,
(-:bob
That draft advises resetting Max-Forwards, but many people (including myself)
think that is not correct because it subverts the intention of Max-Forwards
loop detection, and in fact can potentially create an endless loop.
cheers,
(-:bob
-Original Message-
From: sip-implementors-boun.
inline
>-Original Message-
>From: sip-implementors-boun...@lists.cs.columbia.edu
>[mailto:sip-implementors->boun...@lists.cs.columbia.edu] On Behalf Of Kamini
>Gangwani
>Sent: Thursday, June 17, 2010 1:50 PM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip-implementors] Max-For
I agree with Robert. B2BUAs should decrement Max-Forwards when they are
forwarding requests like a proxy does. I think the only case in which they
might reset it would be a situation like a PBX where it is originating the call.
cheers,
(-:bob
-Original Message-
From: sip-implementors
BTW, that particular URI is not completely correct because the 'user=phone'
indicates that the userinfo in the URI is a phone number, but there is no
userinfo part in that URI.
cheers,
(-:bob
-Original Message-----
From: Bob Penfield
Sent: Wednesday, May 19, 2010 10:23 AM
Parameters inside the <> are URI parameters. Parameters outside the <> are
Header parameters. 'user' is a URI parameter, so user=phone belongs inside the
<>. So "To: " is correct.
cheers,
(-:bob
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-im
inline
>-Original Message-
>From: sip-implementors-boun...@lists.cs.columbia.edu
>[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Brett Tate
>Sent: Tuesday, February 16, 2010 3:11 PM
>To: Aneesh Naik
>Cc: sip-implementors@lists.cs.columbia.edu
>Subject: Re: [Sip-imple
RFC 3261 states that the SDP must be in the first "reliable" non-failure
response (I forget the exact session) to the INVITE. Therefore, if the 180 is
not sent reliably, then the SDP must appear in the 200-OK. It also states that
the SDP in the 180 must be the same in the 200-OK.
-Original
They are 2 different headers.
The "Expires" header is part of the base protocol (RFC 3261). It has different
meaning depending on the method. For an INVITE (sec 13.2, 13.3, 16.10 and
20.19) it defines the expiration period for the INVITE transaction (not the
session). For REGISTER (section 10)
I agree that the RFC is unclear. I think that all that is need is a sentence
that says that if there are no bindings, then the 200-OK does not contain a
Contact header.
Virtually every implementation that I have seen in the last 8 years does it
this way (i.e. 200-OK without any Contact).
Che
If there are no binding remaining, the 200 OK does not need to have a Contact
header. A 200-OK response without any Contacts indicates that there are no
bindings.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.
The registrar should support legacy 2543 endpoints (i.e. phones). It only has
to do this on the server transaction because presumably it would never generate
a request w/o a branch id. Its not that hard.
Cheers,
(-:bob
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia
Section 17.3.2 of RFC 3261 says:
If the branch parameter in the top Via header field is not present,
or does not contain the magic cookie, the following procedures are
used. These exist to handle backwards compatibility with RFC 2543
compliant implementations.
The INVITE request m
I think they meant "embedded" headers, not "escaped" headers.
You are correct, it should say "This INVITE is malformed, as the SIP
Request-URI contains headers".
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.ed
RFC 3261 section 9.1 defines how CANCEL requests are constructed. Section 16.10
talks about how a proxy processes a CANCEL request refers to section 9.1.
Section 16.6 (Request Forwarding) does not apply to CANCELs in a stateful
proxy. IMO, a strict interpretation of these sections would prevent
boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Wednesday, February 04, 2009 9:38 AM
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] [Sip] Is Contact Header mandatory in REFER
message?
2009/2/4 Bob Penfield :
> No, a request that is creating a dialog does not ha
...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Wednesday, February 04, 2009 9:07 AM
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] [Sip] Is Contact Header mandatory in REFER
message?
2009/2/4 Bob Penfield :
> REFER is a dialog establishing requ
A Contact is required for dialog establishing requests (and their 2xx response)
and in-dialog target refresh requests (and their 2xx response). REFER is a
dialog establishing request (when it does not have a to-tag). Also, normally,
REFER creates an implicit subscription and the Contact is neede
A request should only have a To tag if it is an in-dialog request. REGISTER is
not part of a dialog. A REGISTER request never has a To tag.
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Rockson Li (zhengyli)
[EMAIL PROTECTED]
Sent: Friday, Novemb
inline
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iñaki Baz
>Castillo
>Sent: Friday, August 15, 2008 7:07 PM
>To: sip-implementors@lists.cs.columbia.edu
>Subject: [Sip-implementors] Is "Contact" header required in 101-
A CANCEL is an attempt to terminate the INVITE transaction which would
terminate ALL early dialogs. A single BYE cannot be used to terminate ALL early
dialogs. If the UAC wishes to terminate a specific early dialog, then it would
send a BYE. The BYE would include the To and From tags which uniqu
Given the text in 3261 about responding to OPTIONS in the same manner as an
INVITE, it is reasonable to assume that a 481 to OPTIONS means that there is no
INVITE usage for the dialog. But that does not mean that there is no dialog at
all. There may be other usages that exist.
I would say that
Yes. The 200 OK (or the 180 if using 100rel) MUST have the answer.
cheers,
(-:bob
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manpreet Singh
Sent: Friday, April 11, 2008 1:47 PM
To: [EMAIL PROTECTED]; sip-implementors@lists.cs.columbia.edu
Subject: [S
No, the proxy does not send a 487 response. When timer B fires, the proxy sends
a 408 response to the INVITE back to the UAC.
cheers,
(-:bob
-Original Message-
From: Klaus Darilion [mailto:[EMAIL PROTECTED]
Sent: Friday, March 07, 2008 5:21 PM
To: Bob Penfield
Cc: Sip-implementors
The body can contain almost any character, so CRLF is perfectly valid. The body
begins after the empty line following the headers and the Content-Length is
used to determine the end of the body. Many multi-part MIME bodies will contain
empty lines.
cheers,
(-:bob
-Original Message-
Fro
The INVITE transaction must still complete independent of the CANCEL. So the
proxy would continue to re-transmit the INVITE. If the proxy does receive a
provisional response, it would then stop retransmissions and send the CANCEL
down stream. If timer B fired, it would send a 408 response to th
According to RFC 3261:
12.1 Creation of a Dialog
Dialogs are created through the generation of non-failure responses
to requests with specific methods. Within this specification, only
2xx and 101-199 responses with a To tag, where the request was
INVITE, will establish a dialog.
Th
Responses are always sent to the Via.
The Contact defines where to send new Requests.
cheers,
(-:bob
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Corbe
Sent: Tuesday, December 18, 2007 4:05 PM
To: sip-implementors@lists.cs.columbia.edu
Subject:
> 1) All the 200 OK for the CANCEL responses do not contain
> any To-tags. But according to RFC3261 section 16.10, a
> stateful proxy should act as a UAS, which then require
> the response to have a To-tag. Isn't it?
This is an error in RFC 3665. All final responses must have to-tag.
> 2) Assume
No, the UAC does not have the liberty. The to-tag in the CANCEL MUST match the
to-tag in the INVITE begin cancelled. If the INVITE did not have a to-tag, then
the CANCEL MUST NOT have a to-tag.
>From RFC 3261, section 9.1:
The following procedures are used to construct a CANCEL request. The
. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of varun
Sent: Wednesday, July 25, 2007 11:10 AM
To: Bob Penfield; sip-implementors@lists.cs.columbia.edu
The ACK for 2xx is a separate transaction because it needs to go end-to-end.
ACK for 3xx-6xx are hop by hop. The ACK for 2xx is actually the first
request within a dialog. Its Request-URI is the remote target learned from
the 2xx and it includes Route headers from the route set learned from the
2
Note that it is possible for the first NOTIFY request to be received before
the 200-OK to the SUBSCRIBE and that the 'dialog' of the NOTIFY might be
different than the 'dialog' in 200-OK for the SUBSCRIBE if the SUBSCRIBE was
forked. In that case, the Record-Routes from the NOTIFY would be used.
53 matches
Mail list logo
