Re: [Sip-implementors] BroadSoft's use of Diversion Header

[Paul Kyzivat]

Discussion about the compliance of some particular vendor to this is 
probably pointless. The draft was never a standard. It existed as a 
personal draft for a long time, and finally was moved directly from that 
to Historic status, without ever having been a standards track RFC. The 
move to Historic was simply to provide some reference for the 
proprietary implementations of it.

Given this status, your only practical recourse is to implement whatever 
you must to interop with whatever you want to interop with, or else take 
the argument to the implementer you have trouble with.

Thanks,
Paul

On 4/4/12 3:36 AM, Brandon W. Yuille wrote:
> Hi Peter,
>
> One followup that may change everything I said about Broadsoft being
> wrong: rfc 6044.
>
> Looks like this informational rfc addressed the odd syntax you found in
> rfc 5806:
>
> 3.2. Diversion Header Syntax
>
>  The following text is restating the exact syntax that the production
>  rules in [RFC5806] define, but using 
> [RFC5234] ABNF:
>
>   Diversion = "Diversion" HCOLON diversion-params
>*(COMMA diversion-params)
>
>   diversion-params= name-addr *(SEMI (diversion-reason /
> diversion-counter / diversion-limit /
> diversion-privacy / diversion-screen /
> diversion-extension))
>   diversion-reason= "reason" EQUAL ("unknown" / "user-busy" /
> "no-answer" / "unavailable" / "unconditional"
> / "time-of-day" / "do-not-disturb" /
> "deflection" / "follow-me" / "out-of-service"
> / "away" / token / quoted-string)
>   diversion-counter   = "counter" EQUAL 1*2DIGIT
>   diversion-limit = "limit" EQUAL 1*2DIGIT
>   diversion-privacy   = "privacy" EQUAL ("full" / "name" / "uri" /
> "off" / token / quoted-string)
>   diversion-screen= "screen" EQUAL ("yes" / "no" / token /
> quoted-string)
>   diversion-extension = token [EQUAL (token / quoted-string)]
>
>  Note: The Diversion header could be used in the comma-separated
>  format, as described below, and in a header-separated format.  Both
>  formats could be combined a received INVITE as recommended in
>  [RFC3261].
>
>  Example:
>
>  Diversion:
>
>  diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
>  diverting_user1_addr; reason="unconditional"; counter=1; privacy=off
>
>
> So is Broadsoft correctly following the syntax in rfc 5806? No. Are they
> correctly following the current syntax in informational rfc 6044? Yes.
>
> However in my view: in order to be interoperable with devices supporting
> the earlier rfc 5806 draft using the comma separated headers should be
> discouraged. It's also odd to me that this section 3.2 claims "the
> following text is restating the EXACT syntax that the production rules
> in [RFC5806] define, but using [RFC5234] ABNF." I don't see how changing
> the syntax to allow comma separated headers could be called exact.
> Perhaps someone else who's more familiar with this rfc could shed light
> on this apparent discrepancy.
>
> Again, I hope I could help,
> Brandon
>
> On 04/04/2012 03:16 AM, Brandon W. Yuille wrote:
>> Hi Peter,
>>
>> You're correct that their implementation does not follow the syntax for
>> rfc 5806. Though I'm not really sure how much scrutiny that draft received.
>>
>> Is it a real problem? Probably not as I'd be willing to bet most
>> implementations used the same parsing routines for the Diversion header
>> as they would for any other header that contains a name-addr, which all
>> that I can think of that allow multiple header lines also allow
>> combining into one single header line separated by commas. I would think
>> a programmer was rather odd if they chose to write a new parsing routing
>> for name-addr headers that only allowed exactly 1 name-addr per header line.
>>
>> If you're just concerned with pointing out the problem to Broadsoft,
>> then yes you have a valid point as there may be an odd device out there
>> that followed the header syntax exactly. This would lead to interop
>> problems. If Broadsoft were smart about interop they'd just put each
>> Diversion name-addr on a separate line to avoid any such problem. I'd
>> imagine they were looking to save space though.
>>
>> I hope I could help,
>> Brandon
>>
>> On 04/03/2012 10:43 PM, Peter Childs wrote:
>>
>>> I notice that our BroadSoft AS platform on a multiple diverted call sends 
>>> the following to a Network element, where it appears two Diversion are 
>>> concatenated into a single Diversion: header as follows.
>>>
>>> Diversion:"NodePhone";privacy=full;reason=unconditional;counter=1,"N

Re: [Sip-implementors] extracting the CLI for caller ID display: RFC 3325

[Paul Kyzivat]

If you are operating in an environment where a more specialized 
standard/profile holds (such as 3gpp/IMS) then you should look there for 
guidance on what to do.

If not, then you will need to make up your own policies.

Thanks,
Paul

On 4/3/12 9:07 PM, Romel Khan wrote:
> ITU standards, such as, Q.1912.5, imply From header is used for caller id
> display.
>
> On Tue, Apr 3, 2012 at 3:46 PM, Brett Tate  wrote:
>
>>> But this section 8 is written so generically (eg "However,
>>> any specific behavior is specific to implementations or
>>> services") that it is pretty much saying nothing on
>>> the usage of From header vs P-Asserted-ID.
>>
>> 8. User Agent Server Behavior
>>
>>Typically, a user agent renders the value of a P-Asserted-Identity
>>header field that it receives to its user.  It may consider the
>>identity provided by a Trust Domain to be privileged, or
>>intrinsically more trustworthy than the From header field of a
>>request.  However, any specific behavior is specific to
>>implementations or services.  This document also does not mandate any
>>user agent handling for multiple P-Asserted-Identity header field
>>values that happen to appear in a message (such as a SIP URI
>>alongside a tel URL).
>>
>>However, if a User Agent Server receives a message from a previous
>>element that it does not trust, it MUST NOT use the P-Asserted-
>>Identity header field in any way.
>>
>>If a UA is part of the Trust Domain from which it received a message
>>containing a P-Asserted-Identity header field, then it can use the
>>value freely but it MUST ensure that it does not forward the
>>information to any element that is not part of the Trust Domain, if
>>the user has requested that asserted identity information be kept
>>private.
>>
>>If a UA is not part of the Trust Domain from which it received a
>>message containing a P-Asserted-Identity header field, then it can
>>assume this information does not need to be kept private.
>>
>>
>>> On a feature as simple as which header to use for caller
>>> ID display, so one carrier can try to enforce the From
>>> header while another could use the P-Asserted-ID?
>>
>> It is all about trust.  The trust issues were one of the reasons why RFC
>> 5876 is categorized as "Informational" instead of "Standards Track".
>>
>>
>>> Is there no standard pertaining to SIP in IETF and ITU
>>> which clarifies the proper usage?
>>
>> Concerning IETF, see Abstract.  3gpp may be more specific concerning the
>> topic.
>>
>> Abstract
>>
>>This document describes private extensions to the Session Initiation
>>Protocol (SIP) that enable a network of trusted SIP servers to assert
>>the identity of authenticated users, and the application of existing
>>privacy mechanisms to the identity problem.  The use of these
>>extensions is only applicable inside an administrative domain with
>>previously agreed-upon policies for generation, transport and usage
>>of such information.  This document does NOT offer a general privacy
>>or identity model suitable for use between different trust domains,
>>or use in the Internet at large.
>>
>>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Clarification regarding the Cseq to be used in mid dialog req on cloned leg.

[Paul Kyzivat]

On 4/2/12 11:55 AM, Nataraju A.B wrote:
> Ravi,
>
> I partially agree with your comments. If you consider the following
> scenario, it is better to select the local sequence based on the cseq of
> the received response than from one of the dialogs (d1 / d2).

Not sure I understand, and if I do I disagree.

The cseq values sent in opposite directions on a dialog are 
*independent* of one another. The starting value in each direction is 
supposed to be a random number in range [0,2^31-1].

Of necessity these need to be managed independently for each dialog, 
though the the initial value from the UAC will be the same for all 
dialogs resulting from the forking of an initial dialog establishing 
request.

Thanks,
Paul

> Also there is no requirement (from 3261) to clone/copy the local sequence
> number from the existing dialog set.
>
> If we go according to your theory, then we have search through all the
> existing dialoigs and select the one with highest cseq's (may not be worth
> doing). Instead if we select the local seq based on the cseq of the
> received response (OR one with matching half dialog), then it would be
> simple and all of the entities (proxies / UA's) would work without any
> issue with cseq value
>
> INVITE (cseq:1)>
>
> <--- 180 (100rel), cseq:1 Tag-1
> PRACK (cseq:2) --->  Tag-1
> <--- 200 -PRACK, cseq:2, Tag-1
>
> <--- 183 (100rel), cseq:1 Tag-1
> PRACK (cseq:3) --->  Tag-1
> <--- 200 -PRACK, cseq:3, Tag-1
>
> <--- 180 (100rel), cseq:1 Tag-2
> PRACK (cseq:2) --->  Tag-2
> <--- 200 -PRACK, Tag-2
>
> <--- 180 (100rel), cseq:1 Tag-3
> PRACK (cseq:2) --->  Tag-3   *** here cseq should be 3 or 4  
> <--- 200 -PRACK, (cseq:2), Tag-3
>
> Cseq:4 would not create problem for any entity, but is it worth searching
> across all dialogs to find the highest cseq number for an outgoing request.
>
> Even this may not be a problem with CSF (Call Stateful proxies) since each
> request is handled within the purview of a dialog, NOT session.
>
> Typical contents of a dialog include
>
> dialog creating method (INV / UPD / SUB)  - SAME for all dialogs, hence can
> be copied from other dialogs
> Call-ID  - SAME for all dialogs, hence can be copied from other
> dialogs
> Local tag   - SAME for all dialogs, hence can be copied from other
> dialogs
> Local seq num- differ from dialog to dialog depends on the state and
> time  of the dialog,  hence **should not** clone from other dialogs
>
> remote tag   - Always differ from dialog to dialog, hence should
> not clone from other dialogs
> remote seq  - Always differ from dialog to dialog, hence should not
> clone from other dialogs
>
> My 2 cents
>
> Thanks,
> Nataraju A B
>
> On Tue, Mar 27, 2012 at 11:10 AM, Ravi Kumar  wrote:
>
>> Hi,
>> Thanks for reply.
>>
>> So for better interoperability  (with proxies for which RFC is not clear
>> about CSeq for forked leg) if UAC send request with higher CSeq (in below
>> mention scenario CSeq 3) then call be always successful.
>>
>> Please share your opinion.
>>
>> Regards,
>> Ravi Kumar
>>
>>
>> 
>> -
>> This e-mail and its attachments contain confidential information from
>> HUAWEI, which is intended only for the person or entity whose address is
>> listed above. Any use of the information contained herein in any way
>> (including, but not limited to, total or partial disclosure, reproduction,
>> or dissemination) by persons other than the intended
>> recipient(s) is prohibited. If you receive this e-mail in error, please
>> notify the sender by phone or email immediately and delete it!
>>
>> -Original Message-
>> From: Worley, Dale R (Dale) [mailto:dwor...@avaya.com]
>> Sent: Monday, March 26, 2012 9:56 PM
>> To: Ravi Kumar; 'harbhanu sahai'; 'Vinay V';
>> sip-implementors@lists.cs.columbia.edu
>> Subject: RE: [Sip-implementors] Clarification regarding the Cseq to be used
>> in mid dialog req on cloned leg.
>>
>>> From: Ravi Kumar [raviku...@huawei.com]
>>>
>>> But in my opinion it should send request with CSeq 3. Because if some
>> node
>>> in network use CSeq of dialog on which clone response is received then
>> above
>>> implementation will be more flexible.
>>> UAS will not have any impact because as per RFC 3261 this is not error
>>> condition.
>>
>> True, a UAC (request sender) can choose to use a higher CSeq.  But a
>> UAS (request receiver) must not *require* that.
>>
>> However, I believe that your complaint is based on a conceptual error:
>> Forking is an *inherent* part of SIP, and all devices (especially
>> proxies and other "middle boxes") must be prepared to see multiple
>> forks of a single request and must handle them correctly.
>>
>> Once you assume that all SIP elements will handle forked requests
>> properly, then there is no need to worry about behavior that is "more
>> flexible".
>>
>> Dale

Re: [Sip-implementors] Content-Length in multipart bodies

[Paul Kyzivat]

On 3/29/12 10:39 PM, Worley, Dale R (Dale) wrote:

>> I am uncertain what the use would be for supplying these
>> content-length headers for constituent body parts in a multipart,
>> but I am thinking that these headers are probably not errors. I
>> agree with you that it is likely that they would be ignored.
>
> The most liberal interpretation is that Content-Length is allowed in
> multipart bodies, and its value must equal the length of the body
> part, as determined by the MIME framing mechanism.  The most
> conservative interpretation is that Content-Length is only allowed in
> "top level" bodies.
>
> Probably a better question to ask is what is the best practice
> regarding Content-Length headers on body parts?

ISTM that the best practice would be to break out the body based on the 
multipart delimiter. Then if the content-length is present, and less 
than the body extracted, use only as much as described by content-length.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] FW: Clarification regarding the Cseq to be used in mid dialog req on cloned leg.

[Paul Kyzivat]

On 3/26/12 2:45 PM, Ravi Kumar wrote:
> What about proxy, I do not find any text in RFC 3261 for proxy behavior.
> So call stateful proxy can expect CSeq as 3. How to deal with call stateful
> proxy?

You stated *your opinion* that the sender should use CSeq 3.
That doesn't mean that everyone will agree with your opinion.
I posted a reply a few days ago reaching the opposite conclusion.

Why should a proxy care? If for some reason it does care it should 
probably make the most generous interpretation, which is that the next 
CSeq in the dialog should be the last one seen on the dialog (1) plus one.

Thanks,
Paul

> Regards,
> Ravi Kumar
>
> 
> -
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by phone or email immediately and delete it!
>
>
> -Original Message-
> From: Ravi Kumar [mailto:raviku...@huawei.com]
> Sent: Monday, March 26, 2012 5:13 PM
> To: 'harbhanu.sa...@gmail.com'; 'vin...@huawei.com';
> 'sip-implementors@lists.cs.columbia.edu'
> Subject: RE: [Sip-implementors] Clarification regarding the Cseq to be used
> in mid dialog req on cloned leg.
>
> Hi,
> But in my opinion it should send request with CSeq 3. Because if some node
> in network use CSeq of dialog on which forked response is received then
> above implementation will be more flexible.
> UAS will not have any impact because as per RFC 3261 this is not error
> condition.
>
> RFC 3261
>
> 12.2.2 UAS Behavior
>
> If the remote sequence number was not empty, and
> the sequence number of the request is greater than the remote
> sequence number, the request is in order.  It is possible for the
> CSeq sequence number to be higher than the remote sequence number by
> more than one.  This is not an error condition
>
>
> Please share your opinion on this.
>
>
> Regards,
> Ravi Kumar
>
>
> 
> -
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by phone or email immediately and delete it!
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> harbhanu sahai
> Sent: Wednesday, March 21, 2012 6:29 PM
> To: Vinay V
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Clarification regarding the Cseq to be used
> in mid dialog req on cloned leg.
>
> As here 18x will create an 'early dialog', which would be clone of previous
> one. So, the CSeq here should be '2'.
>
> Requests within a dialog MUST contain strictly monotonically
> increasing and contiguous CSeq sequence numbers (increasing-by-one)
> in each direction (excepting ACK and CANCEL of course, whose numbers
> equal the requests being acknowledged or cancelled).  Therefore, if
> the local sequence number is not empty, the value of the local
> sequence number MUST be incremented by one, and this value MUST be
> placed into the CSeq header field.
>
> Also, the below text for re-computation mentions that CSeq should not be
> recomputed on receiving 2xx, since it might have changed owing to
> mid-dialog requests.
>
> Hope it helps.
>
> Thanks,
> Harbhanu
>
>
> On Wed, Mar 21, 2012 at 2:58 PM, Vinay V  wrote:
>
>> Hi All,
>>
>> I wanted clarification regarding the following section in
>> RFC 3261.
>>
>>
>> 13.2.2.4 2xx Responses
>>
>>
>>
>>Multiple 2xx responses may arrive at the UAC for a single INVITE
>>
>>request due to a forking proxy.  Each response is distinguished by
>>
>>the tag parameter in the To header field, and each represents a
>>
>>distinct dialog, with a distinct dialog identifier.
>>
>>
>>
>>If the dialog identifier in the 2xx response matches the dialog
>>
>>identifier of an existing dialog, the dialog MUST be transitioned to
>>
>>the "confirmed" state, and the route set for the dialog MUST be
>>
>>recomputed based on the 2xx response using the procedures of Section
>>
>>12.2.1.2.  Otherwise, a new dialo

Re: [Sip-implementors] "o=" line of multiple SDP Answer sent within forked Provisional responses

[Paul Kyzivat]

On 3/23/12 4:47 PM, Worley, Dale R (Dale) wrote:
>> From: Paul Kyzivat [pkyzi...@alum.mit.edu]
>>
>>> As far as I can tell, in general it does not matter what the o= line
>>> values are, as long as the uniqueness rule is followed:  If two SDP
>>> instances have exactly the same o= lines, then the SDP instances
>>> must be exactly the same.
>>
>> The requirement to be identical must only apply among SDP instances that
>> are related. If two different UAs, in separate dialogs, just *happen* to
>> create otherwise identical SDP instances there certainly cannot be a
>> requirement that the o= values be identical.
>
> Tsk, Paul!  I said "If the o= lines are identical, then the SDP must
> be identical", not "If the SDP is identical, then the o= lines must be
> identical".
>

Sorry Dale, my bad.

But the point remains - it is in theory possible that the same o-line 
could be used in different sessions, in association with other content 
that is not the same. According to 4566,

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Behaviour of Registrar server to take care of erroneous condition....

[Paul Kyzivat]

On 3/23/12 11:36 AM, Kevin P. Fleming wrote:
> On 03/23/2012 10:14 AM, Worley, Dale R (Dale) wrote:
>>> From: Vivek Batra [vivek.ba...@matrixcomsec.com]
>>>
>>> Now Registrar server has two registration bindings of same physical UA viz
>>> IP1 and IP2. Till the timeout of IP1 (by default 3600 seconds), that binding
>>> (IP1) shall remain live in the registrar server. Any proxy module requesting
>>> registrar sever for the location information of UA gets two binding viz IP1
>>> and IP2 however IP1 nowhere exists in the network. Any solution to take care
>>> of this?
>>
>> This situation is not a problem, and therefore does not need a
>> solution:  A request sent to the AOR will be parallel forked to both
>> Contact 1 and Contact 2.  Clearly, the request to Contact 1 will
>> receive no response.  But the request to Contact 2 will reach the UA
>> and receive the proper responses.  The request to Contact 1 will be
>> abandoned or terminated either by timeout or when the UA sends a final
>> response.
>
> Well... pedantically, the request to Contact 1 *may* receive a response,
> if the DHCP server in question has reassigned the address within the
> expiration time of the registration and the device at that address
> happens to have a SIP UA listening on the port specified in the Contact
> URI :-) In that case, I'd expect the fork of the INVITE that went to
> Contact 1 to result in a '404' response.

Sure, that *could* happen. But it *shouldn't* happen for well behaved 
UAs. If the UA has a dynamically assigned address, it should set the 
expiration time for the registration to be no later than the expiration 
time for the address.

Regarding the main point, again a well behaved UA can mitigate the 
problem. When registering its newly assigned contact IP2, it could also 
check for a prior registration by itself. If found, it can remove that 
one. Of course to do this it must recognize the contact as its own. It 
could use a contact header parameter for that. Or, if outbound is in 
use, it can take care of all this.

Thanks,
Paul

> This is yet another case where a UA sending a request can expect
> responses to have some amount of 'reasonableness', but it should be
> prepared for responses to contain completely unexpected contents.
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] "o=" line of multiple SDP Answer sent within forked Provisional responses

[Paul Kyzivat]

On 3/23/12 11:32 AM, Worley, Dale R (Dale) wrote:
>> From: Alexey Entsov [alent...@yahoo.com]
>>
>> The question is: What should be the "o=" line of each SDP Answer? Should it 
>> be unique for each dialog?
>
> As far as I can tell, in general it does not matter what the o= line
> values are, as long as the uniqueness rule is followed:  If two SDP
> instances have exactly the same o= lines, then the SDP instances
> must be exactly the same.

The requirement to be identical must only apply among SDP instances that 
are related. If two different UAs, in separate dialogs, just *happen* to 
create otherwise identical SDP instances there certainly cannot be a 
requirement that the o= values be identical.

Presumably the same is true if its the *same* UA, but in different dialogs.

And that can probably be generalized so the requirement only applies if 
the *intent* is that the recipient recognize them as identical. (This is 
arguable.)

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] "o=" line of multiple SDP Answer sent within forked Provisional responses

[Paul Kyzivat]

On 3/22/12 11:13 PM, Alexey Entsov wrote:
> Hi Everyone,
>
> I was faced with the following question, while working on issues related to 
> inconsistency of SDP "o=" line and call forking.
> E.g. say we have Alice and Bob, both are UAs.
>
> Alice initiates a call to Bob by sending of INVITE w/SDP Offer, but Alice 
> doesn't support UPDATE&PRACK (doesn't matter why).
> Bob would like to provide a kind of early media, so it sends media 
> capabilities with forked 18x (180/183) responses.
>
> So, we have the following call flow:
>
> AliceBob
> INVITE w/SDP0
> -->
> 
>
>   180 w/SDP1, to-tag=1
> <--
>   183 w/SDP2, to-tag=2
> <--
> 
> 200 OK w/SDPn, to-tag=n
> <--
>
> So, here we have multiple SDP Answers sent within different SIP dialog.
> The question is: What should be the "o=" line of each SDP Answer? Should it 
> be unique for each dialog?

It doesn't really matter, because the two dialogs are independent. The 
SDPs of the two dialogs should never be compared to one another. It 
could be that they are sent by independent entities that don't 
coordinate in any way, so there can be no requirements on how they 
relate to one another.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Clarification regarding the Cseq to be used in mid dialog req on cloned leg.

[Paul Kyzivat]

I guess this is a little confusing, and the language may not be as 
precise as it could be.

When you send the initial dialog establishing request you need to create 
some state for the "pending" dialog. Its sort of a "half-dialog" since 
you are waiting for a response to complete it.

When you receive a first response (2xx or even 1xx with a tag, contact, 
etc.) you can establish a dialog for it. (Final if its 2xx, early-dialog 
if its 1xx.) That fills in the missing pieces, including the route set, 
remote contact, etc.)

You can then proceed to use that dialog. You could get a request on it 
(e.g. UPDATE, NOTIFY (if this was a subscribe), etc.) The first such 
received message will establish the first remote CSeq value. After that 
you will check cseq values for subsequent received requests.)

You can also get a 1xx or 2xx with a different tag. That will result in 
establishing a separate dialog. Its probably cleaner to think of it as 
being derived from that pending half-dialog. It is unrelated to anything 
that has happened on the other dialog you established. Depending on how 
you want to optimize your implementation, you may not have completely 
separate structures for this. If you mutate your pending dialog into the 
first early/full dialog, then you will have to "clone" it to create 
another dialog. If so, there is some stuff you might have to roll back. 
Specifically, any remote CSeq value you have as a result of requests 
received on the other dialog will need to be removed, so that the other 
UA on the new dialog can choose its own CSeq.

You chose the initial local CSeq when you sent the dialog establishing 
request. It will be the same when received at both forked destinations. 
They will each expect the *next* message from you to have the next value 
after that. If you have sent subsequent messages on the first dialog, 
bumping your local CSeq, the UA on the other dialog won't have received 
them. So, if you clone the first dialog to create the 2nd you might have 
a wrong local cseq value.

Thanks,
Paul

On 3/21/12 5:28 AM, Vinay V wrote:
> Hi All,
>
>  I wanted clarification regarding the following section in
> RFC 3261.
>
>
> 13.2.2.4 2xx Responses
>
>
>
> Multiple 2xx responses may arrive at the UAC for a single INVITE
>
> request due to a forking proxy.  Each response is distinguished by
>
> the tag parameter in the To header field, and each represents a
>
> distinct dialog, with a distinct dialog identifier.
>
>
>
> If the dialog identifier in the 2xx response matches the dialog
>
> identifier of an existing dialog, the dialog MUST be transitioned to
>
> the "confirmed" state, and the route set for the dialog MUST be
>
> recomputed based on the 2xx response using the procedures of Section
>
> 12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
>
> constructed using the procedures of Section 12.1.2.
>
>
>
>Note that the only piece of state that is recomputed is the route
>
>set.  Other pieces of state such as the highest sequence numbers
>
>(remote and local) sent within the dialog are not recomputed.  The
>
>route set only is recomputed for backwards compatibility.  RFC
>
>2543 did not mandate mirroring of the Record-Route header field in
>
>a 1xx, only 2xx.  However, we cannot update the entire state of
>
>the dialog, since mid-dialog requests may have been sent within
>
>the early dialog, modifying the sequence numbers, for example.
>
>
>
> Does this mean that the other pieces of state in the cloned dialog will
> remain same as the original dialog?
>
>
>
> UAC
>
> |INV-Cseq1>
>
> |
>
> |<--180—Tag:T1-
>
> |
>
> |---Prack—Tag:T1—Cseq2->
>
> |
>
> |ß--180-Tag:T2
>
> |
>
> |---Prack-Tag:T2-Cseq?-->
>
> |
>
>
>
> In the above call flow what should be the Cseq of Prack with Tag:T2.
>
> Should it be 2 or 3??
>
>
>
> Regards
>
> Vinay
>
>
>
> 
> *
> This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!
>
> 
> *
>
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

Re: [Sip-implementors] 405 response for UPDATE

[Paul Kyzivat]

On 3/21/12 3:36 PM, Bob Penfield wrote:
> I see your point, but even in the scenario you describe, there is a re-INVITE 
> that would convey to the UA updated capabilities. It is OK for this stuff to 
> change during the dialog, but the UAs have to rely on those changes being 
> communicated in signaling. Otherwise, there is no point at looking at things 
> like the Allow header.

In some cases the updated info may be reported to the extent that it is 
known. But I suspect there will be many cases where that doesn't work 
out well. (For one, the new UA may not report something at all - no 
Accept, Supports, ... In that case, the B2BUA has no new value to send 
to the other end.)

I'd (personally, not necessarily as sipcore chair) be interested in 
having a discussion on how we might improve on this situation. But I 
expect there aren't a lot who care that much about it.

Thanks,
Paul

> cheers,
> (-:bob
>
>
>
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul 
> Kyzivat
> Sent: Wednesday, March 21, 2012 12:06 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] 405 response for UPDATE
>
> Ahh, you found an old email of mine. :-)
>
> There are many of these things in sip where support for *something* is
> declared somewhere. For the most part there is no guarantee how long
> this support is promised to remain, or in what scopes they hold.
>
> We could *try* to tighten these up, but doing so would break some things.
>
> The use case I usually use to identify such issues is 3pcc - where there
> is a B2BUA call controller between a caller and a callee. The controller
> may usually try to act like a proxy - relaying requests to the other
> end. But this means it has to reflect the capabilities and limitations
> of one end to the other, because otherwise it may be asked to do
> something that it can't forward and can't emulate. The controller can
> then do a transfer, replacing one of the endpoints with a new one. The
> other end doesn't see this as a transfer, just a reinvite. But once this
> is done, the new endpoint might not have the same capabilities and
> restrictions as the old one. So the controller may have to report the
> change. To the unchanged endpoint this will appear as a mid-dialog
> change of its peer's capabilities. It could show up as a 405.
>
>   Thanks,
>   Paul
>
> On 3/21/12 10:06 AM, harbhanu sahai wrote:
>> Also, as per 3261 the Allow header present in provisional is valid untill
>> the dialog is in early state.
>>
>>  Header fields present in a provisional
>>  response are applicable as long as the dialog is in the early state
>>  (for example, an Allow header field in a provisional response
>>  contains the methods that can be used in the dialog while this is in
>>  the early state).
>>
>> On the other hand for Allow present in 2xx, lists methods supported for the
>> "duration of call"
>>
>>  A 2xx response to an INVITE SHOULD contain the Allow header field and
>>  the Supported header field, and MAY contain the Accept header field.
>>  Including these header fields allows the UAC to determine the
>>  features and extensions supported by the UAS for the duration of the
>>  call, without probing.
>>
>> Found an old archive which underscores the point that the Allow header
>> content can be updated within a dialog.
>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020143.html
>>
>>
>> But now what's confusing is this --
>> "The scope of these things is very unclear. About all you can
>> ***reliably **assume
>> is that they are true at the time they are conveyed***. "
>>
>> Regards,
>> Harbhanu
>>
>> On Wed, Mar 21, 2012 at 6:55 PM, Bob Penfieldwrote:
>>
>>> I guess that depends on your interpretation of integral to the usage. If
>>> the UA is using UPDATE which includes SDP to modify the session parameters,
>>> it is important for that session. What is the UA supposed to do? It was
>>> told that it could use UPDATE, so it did. Is it supposed to try UPDATE and
>>> then if that fails use INVITE? Why would UPDATE be OK at the beginning of
>>> the session and then not be OK later? If there were no other transactions
>>> that included an Allow header, how is the UA supposed to know that it is
>>> not OK now? If that is the case, then the Allow header is useless.
>>>
>>> It just does not

Re: [Sip-implementors] 405 response for UPDATE

[Paul Kyzivat]

Ahh, you found an old email of mine. :-)

There are many of these things in sip where support for *something* is 
declared somewhere. For the most part there is no guarantee how long 
this support is promised to remain, or in what scopes they hold.

We could *try* to tighten these up, but doing so would break some things.

The use case I usually use to identify such issues is 3pcc - where there 
is a B2BUA call controller between a caller and a callee. The controller 
may usually try to act like a proxy - relaying requests to the other 
end. But this means it has to reflect the capabilities and limitations 
of one end to the other, because otherwise it may be asked to do 
something that it can't forward and can't emulate. The controller can 
then do a transfer, replacing one of the endpoints with a new one. The 
other end doesn't see this as a transfer, just a reinvite. But once this 
is done, the new endpoint might not have the same capabilities and 
restrictions as the old one. So the controller may have to report the 
change. To the unchanged endpoint this will appear as a mid-dialog 
change of its peer's capabilities. It could show up as a 405.

Thanks,
Paul

On 3/21/12 10:06 AM, harbhanu sahai wrote:
> Also, as per 3261 the Allow header present in provisional is valid untill
> the dialog is in early state.
>
> Header fields present in a provisional
> response are applicable as long as the dialog is in the early state
> (for example, an Allow header field in a provisional response
> contains the methods that can be used in the dialog while this is in
> the early state).
>
> On the other hand for Allow present in 2xx, lists methods supported for the
> "duration of call"
>
> A 2xx response to an INVITE SHOULD contain the Allow header field and
> the Supported header field, and MAY contain the Accept header field.
> Including these header fields allows the UAC to determine the
> features and extensions supported by the UAS for the duration of the
> call, without probing.
>
> Found an old archive which underscores the point that the Allow header
> content can be updated within a dialog.
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020143.html
>
>
> But now what's confusing is this --
> "The scope of these things is very unclear. About all you can
> ***reliably **assume
> is that they are true at the time they are conveyed***. "
>
> Regards,
> Harbhanu
>
> On Wed, Mar 21, 2012 at 6:55 PM, Bob Penfieldwrote:
>
>> I guess that depends on your interpretation of integral to the usage. If
>> the UA is using UPDATE which includes SDP to modify the session parameters,
>> it is important for that session. What is the UA supposed to do? It was
>> told that it could use UPDATE, so it did. Is it supposed to try UPDATE and
>> then if that fails use INVITE? Why would UPDATE be OK at the beginning of
>> the session and then not be OK later? If there were no other transactions
>> that included an Allow header, how is the UA supposed 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 [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 integral to the INVITE usage, it would have been defined
>> within RFC 3261.
>>
>>> -Original Message-
>>> From: Bob Penfield [mailto:bpenfi...@acmepacket.com]
>>> Sent: Wednesday, March 21, 2012 8:50 AM
>>> To: Brett Tate; Kashif Husain; sip-implementors@lists.cs.columbia.edu
>>> Subject: RE: [Sip-implementors] 405 response for UPDATE
>>>
>>> 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 the condition is unrecoverable
>>>and should stop sending NOTIFYs on the usage.  Any refresh
>>>subscriptions should be rejected.  In general, these errors will
>>>affect at most the usage.  If the request was not integral to the
>>>usage (it used an unknown method, or was an INFO inside an INVITE
>>>usage, for example), only the transaction will be affected.
>>>
>>> Typically UPDATE is integral to the INVITE usage.
>>>
>>>
>>> cheers,
>>> (-:bob
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Brett Tate
>>> Sent: Wednesday, March 21, 2012 8:46 AM
>>> To: Kashif Husain; sip-implementors@lists.cs.columbia.edu
>>> Subject: Re: [Sip-implementors]

Re: [Sip-implementors] Does Dialog Lifetime affect dialog creating transaction lifetime?

[Paul Kyzivat]

I agree with Brett and Dale.

Transactions exist at a logically lower layer than dialogs. Changing 
state of the dialog does not affect any transaction. Each transaction 
must follow its state machine independently.

Regarding how long to allow ringing ringing to continue: IMO this needs 
to be closely coupled to the application/UI. The UAS should make its own 
decision, and perhaps have a policy to reject the call if its alerting 
doesn't result in an answer in some reasonable time. The UAC side may 
want to keep the call up as long as the callee is willing and its own 
user hasn't hung up. But if there is a chance that the UAC is unattended 
it might want to give up eventually. (There is a tradeoff here with 
disappointing a user that *wants* the call to continue ringing.)

Thanks,
Paul

On 3/20/12 1:59 PM, Worley, Dale R (Dale) wrote:
>> From: M. Ranganathan [mra...@gmail.com]
>>
>> Consider the following two scenarios:
>>
>> Scenario 1
>> =
>> Invite Client Transaction sent by UAc creates a Dialog.
>> - Sends INVITE
>> - Server side sends RINGING periodically once every 30 seconds for ever.
>>
>> Dialog remains in early state for 3 minutes and times out.
>>
>> What happens to the INVITE Client Transaction ? Should the SIP stack
>> automatically terminate it?
>>
>> Scenario 2
>> =
>> Invite Server transaction gets INIVTE.
>> Application creates a dialog.
>> Application keeps sending 180 periodically once every 30 seconds for ever.
>> Server Dialog times out after 3 minutes in early state.
>> What should the SIP stack do with the invite Server Transaction?
>> Should it be automatically deleted after the Dialog times out?
>
> I'm not sure, but I think you believe that the transaction is required
> to time out after 3 minutes.  That is not true.  Searching for "3
> minute" in RFC 3261 turns up a few uses, whose import is that the UAC
> times out its request if more than 3 minutes elapse between responses
> that it receives.  Within RFC 3261, if the UAS sends 180 every 30
> seconds forever, the UAC is not required to terminate the transaction.
>
> Now, if the UAC's Timer C expires because it doesn't receive responses
> for long enough, the UAC should terminate the transaction.  As Brett
> noted, the UAC can send BYE on the early dialog to terminate just that
> early dialog, or it can send CANCEL to cancel that fork of the INVITE,
> or all forks of the INVITE.  But RFC 3261 only requires that Timer C
> be *at least* 3 minutes.
>
> For humanity's sake, a UAC should terminate a ringing dialog after
> some long period of time, and send a 4xx response.  But RFC 3261 does
> not require that.
>
> Dale
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] sip implementation in vhdl

[Paul Kyzivat]

On 3/18/12 12:36 PM, Nikos Tzanis wrote:
> On 17/3/2012 8:00 μμ, Paul Kyzivat wrote:
>> Nikos,
>>
>> Following on to what has been said...
>>
>> Typically one would not set out to solve a problem in hardware unless
>> there has been a demonstrated problem solving it in software. And, as
>> Brandon says, you can't realistically expect to do the *whole* job in
>> hw, so you will need something that can host the software part. So
>> really you are talking about building a hw accelerator for a sw
>> implementation.
>>
>> So, I would recommend looking around for a suitable sw implementation,
>> and then study what could be accelerated. This probably makes no sense
>> at all in a single user endpoint. There *might* be something to gain in
>> a server, such as an SBC.
>>
>>  Good luck,
>>  Paul
>>

> First of all thank you for the quick replies .I want you to know that I
> m not trying to implement a commercial porduct but to go as far as i can
> for educational reasons. So a simple model with them main features of
> SIP would be ok . The first module(parser) is almost ready .When a
> message arrive , i can find all the header-header value pairs and save
> it in memory . Where a cpu could easilly find them . Surely a cpu is
> needed , but if i could create standard messages too(with the minimum
> fields required. To,From,Cseq,Call-id,Max Forward,Via . ) . I mean if
> hardware could find these stored values and send the message ? But how
> to go from the simple transaction model to vhld???where can i find the
> techniques?
>
>   thanks a lot once more
> Nikos Tzanis

I'm not a hw guy, so I have nothing more to add on this subject.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Ambiguity while mandating answer in reliable-1xx and 2xx

[Paul Kyzivat]

On 3/17/12 3:02 PM, Nataraju A.B wrote:
> Paul, Thanks for the clarification, I got the point...
>
> According to the Pattern 3 of rfc6337, following scenario is a valid.
>
> UAC   UAS
> INV (SDP-A)->
> *<--- rel-1xx (no SDP)*
> <--- rel-1xx ( SDP-B )
> <--- rel-1xx (no SDP)
> <--- 2xx ( no SDP)

Yes.

> My next question is with respect to content in RFC3261.
>
> Why the first the answer must be in *one of the reliable responses*
> (early media scenario). whereas in the delayed media scenario the offer
> *must *be in *first *reliable response.
>
> was this requirement derived from PSTN / ISDN /  
>
> Why not both of them to be *MUST* requirements / *one of* requirements
> (just out of curiosity) 

I have not been able to discover an answer to this. It may have been a 
mistake. This was discussed many years ago. Nobody could come up with a 
strong argument for this restriction. We also discussed removing it. But 
concluded that doing so would be a backward incompatibility, and making 
it support of a change optional would be worse than leaving it as it is.

Thanks,
    Paul

> Thanks,
> Nataraju A B
>
> On Sat, Mar 17, 2012 at 11:48 PM, Paul Kyzivat  <mailto:pkyzi...@alum.mit.edu>> wrote:
>
> Inline
>
> On 3/17/12 1:44 PM, Nataraju A.B wrote:
>  > Hi All,
>  >
>  > Following is the excerpt from the RFCs 3261 and 6337, with respect to
>  > Answer being carried in Reliable-1xx and 2xx-INV
>  >
>  > <3261>
>  >
>  >o  If the initial offer is in an INVITE, the answer *MUST
> *be in a
>
> Note the last word above is "a", not "the first".
>
>  >   reliable non-failure message from UAS back to UAC which is
>  >   correlated to that INVITE.  For this specification, that is
>  >   only the final 2xx response to that INVITE.  That same
> exact
>  >   answer MAY also be placed in any provisional responses sent
>  >   prior to the answer.  The UAC MUST treat the first session
>  >   description it receives as the answer, and MUST ignore any
>  >   session descriptions in subsequent responses to the initial
>  >   INVITE.
>  >
>  > 
>  >
>  > <6337>
>  >
>  > In Pattern 3, the first reliable provisional response *may or
> may not*
>  > have an answer.  When a reliable provisional response contains a
>  > session description, and is the first to do so, then that session
>  > description is the answer to the offer in the INVITE request.
>   The
>  > answer cannot be updated, and a new offer cannot be sent in a
>  > subsequent reliable response for the same INVITE transaction.
>  >
>  > 
>  >
>  > Looks like rfc6337 is little bit deviating from 3261's intention.
>  >rfc6337 - may or may not requirement for carrying answer in
> reliable 1xx
>  >rfc3261 - MUST requirement for carrying answer in 2xx/reliable
>  > non-failure response
>  >
>  > Am I missing something here 
>
> Yes.
>
> When the offer is in the invite, the answer must be in a reliable
> response, but it need not be the first reliable response. 3261 says this
> and 6337 restates it in a way that is hopefully clearer.
>
> I think you are mixing this up with the prior paragraph in 3261:
>
>o  The initial offer MUST be in either an INVITE or, if not
> there,
>   in the first reliable non-failure message from the UAS back to
>   the UAC.  In this specification, that is the final 2xx
>   response.
>
> Namely, its when there is no offer in the INVITE that it must be in the
> *first* reliable response. This is covered by patterns 2 and 4 of 6337.
>
> Thanks,
> Paul
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
>
> --
> Thanks,
> Nataraju A.B.
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Ambiguity while mandating answer in reliable-1xx and 2xx

[Paul Kyzivat]

Inline

On 3/17/12 1:44 PM, Nataraju A.B wrote:
> Hi All,
>
> Following is the excerpt from the RFCs 3261 and 6337, with respect to
> Answer being carried in Reliable-1xx and 2xx-INV
>
> <3261>
>
>o  If the initial offer is in an INVITE, the answer *MUST *be in a

Note the last word above is "a", not "the first".

>   reliable non-failure message from UAS back to UAC which is
>   correlated to that INVITE.  For this specification, that is
>   only the final 2xx response to that INVITE.  That same exact
>   answer MAY also be placed in any provisional responses sent
>   prior to the answer.  The UAC MUST treat the first session
>   description it receives as the answer, and MUST ignore any
>   session descriptions in subsequent responses to the initial
>   INVITE.
>
> 
>
> <6337>
>
> In Pattern 3, the first reliable provisional response *may or may not*
> have an answer.  When a reliable provisional response contains a
> session description, and is the first to do so, then that session
> description is the answer to the offer in the INVITE request.  The
> answer cannot be updated, and a new offer cannot be sent in a
> subsequent reliable response for the same INVITE transaction.
>
> 
>
> Looks like rfc6337 is little bit deviating from 3261's intention.
>rfc6337 - may or may not requirement for carrying answer in reliable 1xx
>rfc3261 - MUST requirement for carrying answer in 2xx/reliable
> non-failure response
>
> Am I missing something here 

Yes.

When the offer is in the invite, the answer must be in a reliable 
response, but it need not be the first reliable response. 3261 says this 
and 6337 restates it in a way that is hopefully clearer.

I think you are mixing this up with the prior paragraph in 3261:

   o  The initial offer MUST be in either an INVITE or, if not there,
  in the first reliable non-failure message from the UAS back to
  the UAC.  In this specification, that is the final 2xx
  response.

Namely, its when there is no offer in the INVITE that it must be in the 
*first* reliable response. This is covered by patterns 2 and 4 of 6337.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] sip implementation in vhdl

[Paul Kyzivat]

Nikos,

Following on to what has been said...

Typically one would not set out to solve a problem in hardware unless 
there has been a demonstrated problem solving it in software. And, as 
Brandon says, you can't realistically expect to do the *whole* job in 
hw, so you will need something that can host the software part. So 
really you are talking about building a hw accelerator for a sw 
implementation.

So, I would recommend looking around for a suitable sw implementation, 
and then study what could be accelerated. This probably makes no sense 
at all in a single user endpoint. There *might* be something to gain in 
a server, such as an SBC.

Good luck,
Paul

On 3/17/12 12:31 PM, Brandon W. Yuille wrote:
> The biggest problem I foresee is that you're trying to do something in
> hardware which is normally done in software. With Nataraju's list I
> would say the only point you can realistically accomplish in hardware
> would be point 1. He also forgot to mention you'll need to handle
> potentially the Ethernet MAC layer (must be hardware), IP/ARP, and UDP
> transport which all could be done in hardware. With everything else
> you're probably going to need to implement a soft core or use an
> external cpu. Without one, you'd be attempting a monolithic problem that
> most likely couldn't be built in under a year. So if you end up using a
> cpu you may as well do all the protocol layers in software along with
> the parsing to make your task easy.
>
> Good luck,
> Brandon
>
> On 03/17/2012 08:51 AM, Nataraju A.B wrote:
>> Tzanis,
>>
>> Simplest proposition would be to use the bottom-up approach.
>>
>> start with
>>   1. Parser (encode/decoder) module
>>   2. Transaction module (initially you design this module one for UA
>> only, exclude proxy specific
>>processing to start with - for simplicity only)
>>   3. Dialog module
>>   4. Session module
>>   5. Some application on top of SIP.
>>
>> One more suggestion would be to go through the OSIP / asterisk / others...
>> First you understand the basics, then you can proceed with VHDL based
>> implementation...
>>
>> hope this helps...
>>
>> Thanks,
>> Nataraju A B
>>
>> 2012/3/17 νικος τζανης
>>
>>
>>> Hello , I am a student and i was asked to implement sip in fpga . I have
>>> studied the rfc 3261 but i dont know where to start from .Sip is a
>>> transaction based protocol . Do you have any idea on how to do this thing?
>>> I have found system offload engine (SOE) implementations but i want to
>>> implement the whole transition model in vhld . Any help would be
>>> appreciated .
>>>
>>>
>>> Nikos Tzanis
>>> ___
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>>
>>
>>
>>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] INVITE request with no value in Content type header

[Paul Kyzivat]

Rejecting the request would be ok.
If you are trying to minimize failure cases then ignoring this might 
give you a chance for the message to work. IMO the header with no value 
is plausibly the same as no header, even though it is a syntax violation.

If you ignore, and there is no body, then all should be fine.
If you ignore and there is a body then you will want to assume the 
default type, which depends on the message. For INVITE, etc. this is 
application/sdp.

Thanks,
Paul

On 3/15/12 11:11 AM, Worley, Dale R (Dale) wrote:
> As others have said, the header is syntactically incorrect, which
> would suggest a 400 error.
>
> As a fallback, you could simply ignore the header, which leads to several
> alternative strategies.  But given that the sending device clearly has an 
> error, it is
> probably best to cause the communications to fail and force the other UA's
> user to debug it.
>
> Dale
>
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of manju nath 
> [manju...@gmail.com]
> Sent: Thursday, March 15, 2012 8:43 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] INVITE request with no value in Content type  
>   header
>
> HI,
>
>  what should be the behaviour of UAS if it receives an INVITE request
> with Content-Type header with no value as shown
>
>   Content-Type:
>
>what should be the response that UAS has to give 400 or 415
>
> --
> *Thanks&  Regards,*
> *Manjunath.jootoor.*
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] VIA header problem in SIP UAS

[Paul Kyzivat]

I agree with Brett.

I will add that you can be over zealous in your checking.
You didn't mention *which* Via header was bothering you.
Its important to you that the *topmost* Via header be well formed enough 
for you to use it to construct a response.

It is *not your problem* of some other Via header appears malformed to 
you. Presumably it wasn't malformed enough to bother the server that 
will need to use it. So in this case you would be well advised to ignore 
this.

Thanks,
Paul

On 3/12/12 8:34 AM, Brett Tate wrote:
>> UAS receives an INVITE request withh invalid Via Header,
>> while parsing we found that syntax of Via is wrong so
>> UAS decided to send 4xx response&  not concentrated on
>> rest of header values.
>
> Sometimes a request is too malformed to bother sending a 400 response.  The 
> following are some of the mandatory headers which would cause a 400 if they 
> were missing: Via, To, From, Call-ID, and CSeq.  However if you sent the 400 
> response, it would also be malformed and might not be able to match the 
> malformed request anyway.
>
> Thus you can act "Ideally" per RFC 4475 section 3.3.1 and send a 400 
> response; or you can act non "Ideally" and ignore it.
>
> The same applies when the mentioned headers are too malformed to adequately 
> build a 400 response.
>
>
>> Is that mandatory to have Via header in 4xx response ?
>
> Yes.
>
>
>> if yes what should be the value of the address and
>> branch parameter in Via header?
>
> The values received with parameters such as received added if needed.
>
>
>> can i use the value of UAS in place of Via header's address
>> and branch parameter?
>
> No.
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Possible SIP REINVITE Scenarios

[Paul Kyzivat]

On 3/8/12 5:05 PM, Sajeewa Don wrote:
> Thank you for your replies.
> One particular scenario I'm trying to understand is why in some
> occasions we see sip re-invite before the termination of a call.
>
>
> Below is an example,
>
> SIP reinvites at the very end of a call (before terminate) with sdp
> ""sendonly", and respond from the other party 200 OK with sdp "recieveonly"

This behavior may seem odd to you. But presumably the other end thinks 
it has a reason for it, whether it is a good one or not. If you really 
want to know, and you know who makes that device, you could always ask. 
But its probably not worthwhile to speculate. There is nothing *wrong* 
with what you are showing. So my advice is to just accept it.

Thanks,
Paul

> CALL FLOW DIAGRAM
>
>
>
> |36602.618| INVITE SDP (g711A g711U g729 g721
> telephone-ev...RTPType-101)  |SIP From:  To: | |(5060)   -->  (5060)   |
> |36602.619| 100 Trying|   |SIP Status
> | |(5060) <--  (5060)   |
> |36603.055| RTP (g711A)   |RTP Num packets:2466
> Duration:49.299s SSRC:0x68BDE27D
> | |(1024) <--  (18148)  |
> |36603.082| 183 Session Progress SDP (g711A
> telephone-even...PType-101)  |SIP Status
> | |(5060) <--  (5060)   |
> |36603.366| RTP (g711A)   |RTP Num packets:174
> Duration:3.458s SSRC:0x4505ED2C
> | |(1024)   -->  (18148)  |
> |36606.840| 200 OK SDP (g711A
> telephone-eventRTPType-101)  |SIP Status
> | |(5060) <--  (5060)   |
> |36606.845| RTP (g711A)   |RTP Num packets:2275
> Duration:45.480s SSRC:0x4505ED2C
> | |(1024)   -->  (18148)  |
> |36606.870| ACK   |   |SIP Request
> | |(5060)   -->  (5060)   |
> |36652.342| INVITE SDP (g711A
> telephone-eventRTPType-101)  |SIP Request
> | |(5060) <--  (5060)   |
> |36652.346| RTP (g711A)   |RTP Num packets:4
> Duration:0.056s SSRC:0x4505ED2C
> | |(1024)   -->  (18148)  |
> |36652.359| 200 Ok SDP (g711A
> telephone-eventRTPType-101)  |SIP Status
> | |(5060)   -->  (5060)   |
> |36652.375| RTP (g711A)   |RTP Num packets:22
> Duration:0.420s SSRC:0x68BDE27D
> | |(1024) <--  (18148)  |
> |36652.410| ACK   |   |SIP Request
> | |(5060) <--  (5060)   |
> |36652.879| BYE   |   |SIP Request
> | |(5060) <--  (5060)   |
> |36652.891| 200 Ok|   |SIP Status
> | |(5060)   -->  (5060)   |
>
> Thanks,
>
> Sajeewa
>
>
> On Fri, Mar 9, 2012 at 4:22 AM, Paul Kyzivat  <mailto:pkyzi...@alum.mit.edu>> wrote:
>
> On 3/8/12 8:32 AM, Kevin P. Fleming wrote:
>  > On 03/07/2012 07:01 PM, Sajeewa Don wrote:
>  >> I would like to understand different possible SIP REINVITE
> Scenarios.
>  >>>  From my knowledge there are three occasions where reinvite
> could occur,
>  >>
>  >> Scenario 1 - To make a Call On Hold by sending a reinvite with
>  >> sendonly/recieveonly
>  >> Scenario 2 - To change parameters of the original connecting
> information
>  >> Scenario 3 - Allows periodic refresh of the SIP sessions through
> re-INVITE
>  >>
>  >> Is there any other possibile Reinvite scenarios?
>  >>
>  >> If you could share your knowledge on this that would be great.
>  >
>  > There are probably an infinite number of scenarios in which a
> re-INVITE
>  > could be issued. What do you believe is the value of trying to
> identify
>  > all possible reasons that you might receive a re-INVITE?
>
> I agree.
>
> To the original poster:
>
> Is the goal to for the UAS to figure out *why* a particular reinvite was
> sent?
>
> That is a fools errand. You in general can't, and shouldn't try to,
> know. Your behavior to a reinvite should not be based on knowing *why*,
> it should simply respond to what is being proposed, in the context of
> your current knowledge of your own state and policies.
>
> For instance, a reinvite w/sendonly is not necessarily an indicatio

Re: [Sip-implementors] Possible SIP REINVITE Scenarios

[Paul Kyzivat]

On 3/8/12 8:32 AM, Kevin P. Fleming wrote:
> On 03/07/2012 07:01 PM, Sajeewa Don wrote:
>> I would like to understand different possible SIP REINVITE Scenarios.
>>>  From my knowledge there are three occasions where reinvite could occur,
>>
>> Scenario 1 - To make a Call On Hold by sending a reinvite with
>> sendonly/recieveonly
>> Scenario 2 - To change parameters of the original connecting information
>> Scenario 3 - Allows periodic refresh of the SIP sessions through re-INVITE
>>
>> Is there any other possibile Reinvite scenarios?
>>
>> If you could share your knowledge on this that would be great.
>
> There are probably an infinite number of scenarios in which a re-INVITE
> could be issued. What do you believe is the value of trying to identify
> all possible reasons that you might receive a re-INVITE?

I agree.

To the original poster:

Is the goal to for the UAS to figure out *why* a particular reinvite was 
sent?

That is a fools errand. You in general can't, and shouldn't try to, 
know. Your behavior to a reinvite should not be based on knowing *why*, 
it should simply respond to what is being proposed, in the context of 
your current knowledge of your own state and policies.

For instance, a reinvite w/sendonly is not necessarily an indication 
that the other end is putting the call on hold. All you know is that you 
aren't allowed to send media to it. Also, once there is more than one 
m-line in the call (e.g. audio & video) then they may have inconsistent 
selections for sendrecv/..., so its hard to classify the call itself as 
held or not. (I suggest you look at RFC6337. Take special note of 
section 5.)

Also, every reinvite, whatever else it changes or does not change, 
serves as a reset or refresh of session timer. This is true whether it 
is periodic or not.

And don't forget reinvites with no offer. You need to support them too, 
in spite of now having a clue of why you received it.

Good Luck,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding SDP attributes

[Paul Kyzivat]

On 3/8/12 4:17 AM, venu Y wrote:
> Yes, it won't make sense...
>
> But, in general while parsing SDP, take the most recent... instead of
> strictly rejecting the offer.

The Postel maxim is to be strict in what you send and liberal in what 
you receive. The flaw in that is that there are often multiple 
conflicting ways in which to be liberal. So being liberal will help when 
dealing with somebody who screwed up in the way you assumed, but won't 
help with those that screwed up some other way.

Here there are rational arguments for taking the first and taking the 
last. The person that sent two values was obviously confused, but you 
don't know which of the attributes was the right one.

The merit of taking the last is that it is typically *easier* to 
program. That is especially the case when, for some things, you can 
legally have an attribute at session level and then override it at media 
level. For that, each time you encounter an m-line you need to make a 
fresh copy of the session level c= values and attributes, and then 
replace them if you encounter them again before the next m-line.

But the bottom line is: put at most *one* of 
sendrecv/sendonly/recvonly/inactive at session level, and at most one of 
them after each m-line.

Thanks,
Paul

> On Thu, Mar 8, 2012 at 1:33 PM, Pranab Bohrawrote:
>
>> An Offer can have both the attribute, but not within the same media
>> description.
>> It doesn't make sense to have both sendonly and sendrecv attributes for
>> the same media description.
>> The specs do not explicitly explain how to handle such a situation, I
>> would say, the UA receiving it should respond back with 488 Not Acceptable
>> Here.
>>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of venu Y
>> Sent: Thursday, March 08, 2012 1:10 PM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: [Sip-implementors] Regarding SDP attributes
>>
>> I think we should take last a= line
>>
>>
>> Does that mean we cannot send both the attributes in one-offer.
>> I think in such case end point should pick last a: line. My guess. Please
>> let me know with little explanation.
>>
>> Thanks,
>> -Abhishek
>>
>> On Wed, Mar 7, 2012 at 4:05 PM, Worley, Dale R (Dale)>> wrote:
>>
>>> No:  their meanings are incompatible.
>>>
>>> Dale
>>>
>>> 
>>> From: sip-implementors-boun...@lists.cs.columbia.edu [
>>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Abhishek
>>> Lal [abhishek.k...@gmail.com]
>>> Sent: Tuesday, March 06, 2012 7:53 PM
>>> To: sip-implementors@lists.cs.columbia.edu
>>> Subject: [Sip-implementors] Regarding SDP attributes
>>>
>>> Hi All,
>>>
>>> Can we send both attributes (sendrecv&  sendonly) in single Request.
>>>
>>>   a=rtpmap:0 PCMU/8000/1
>>> a=rtpmap:8 PCMA/8000/1
>>> *a=sendrecv*
>>> a=ptime:20
>>> *a=sendonly*
>>> *
>>> *
>>> *
>>> *
>>> **
>>> Regards,
>>> -Abhishek
>>> ___
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> SASKEN BUSINESS DISCLAIMER: This message may contain confidential,
>> proprietary or legally privileged information. In case you are not the
>> original intended Recipient of the message, you must not, directly or
>> indirectly, use, disclose, distribute, print, or copy any part of this
>> message and you are requested to delete it and inform the sender. Any views
>> expressed in this message are those of the individual sender unless
>> otherwise stated. Nothing contained in this message shall be construed as
>> an offer or acceptance of any offer by Sasken Communication Technologies
>> Limited ("Sasken") unless sent with that express intent and with due
>> authority of Sasken. Sasken has taken enough precautions to prevent the
>> spread of viruses. However the company accepts no liability for any damage
>> caused by any virus transmitted by this email.
>> Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html
>>
>
>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding SDP attributes

[Paul Kyzivat]

On 3/7/12 12:53 PM, Abhishek Lal wrote:
> Does that mean we cannot send both the attributes in one-offer.
> I think in such case end point should pick last a: line. My guess. Please
> let me know with little explanation.

You didn't reply to my last query. *Why* do you want to include both in 
one offer? And what do you think doing so would mean.

Your question implies to be that you have a fundamental misunderstanding 
of what these things mean. So please say more so we can clarify for you.

Thanks,
Paul

> Thanks,
> -Abhishek
>
> On Wed, Mar 7, 2012 at 4:05 PM, Worley, Dale R (Dale)wrote:
>
>> No:  their meanings are incompatible.
>>
>> Dale
>>
>> 
>> From: sip-implementors-boun...@lists.cs.columbia.edu [
>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Abhishek Lal
>> [abhishek.k...@gmail.com]
>> Sent: Tuesday, March 06, 2012 7:53 PM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: [Sip-implementors] Regarding SDP attributes
>>
>> Hi All,
>>
>> Can we send both attributes (sendrecv&  sendonly) in single Request.
>>
>>   a=rtpmap:0 PCMU/8000/1
>> a=rtpmap:8 PCMA/8000/1
>> *a=sendrecv*
>> a=ptime:20
>> *a=sendonly*
>> *
>> *
>> *
>> *
>> **
>> Regards,
>> -Abhishek
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SDP Attributes

[Paul Kyzivat]

On 3/6/12 8:00 PM, Abhishek Lal wrote:
> Hi All,
>
> Can we send both attributes (sendrecv&  sendonly) in single Request.
>
> a=rtpmap:0 PCMU/8000/1
> a=rtpmap:8 PCMA/8000/1
> *a=sendrecv*
> a=ptime:20
> *a=sendonly*

No. What do you imagine this to mean?

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] [Opalvoip-devel] Capability negotiation control

[Paul Kyzivat]

On 3/6/12 3:18 AM, Robert Jongbloed wrote:
> It can, but it is, IMHO, a complete pain!
>
>
>
> The specification actually says that the selection of codec is not really
> completed until the RTP packets arrive.
>
> Actually, a strict interpretation (I think) of the specification means at
> any time during the session it could send a frame of H.263, then a frame of
> H.264, then a frame of H.261! But that vanishingly unlikely to work in
> practice and no one would be insane enough to do it. J

But its not as unreasonable as you might think.

Once case - any audio codec + telephone-events as a 2nd codec. Frames of 
these are then intermixed.

Another is when multiple RTP streams are multiplexed on the same RTP 
session - distinguished by SSRC. (I may have the terminology wrong 
there.) This hasn't been considered much in sip until recently, but is 
now increasingly going to be used.

A robust implementation should be prepared to handle all of this, and do 
something reasonable. (But I realize there are a lot of widely used 
implementations that are not prepared for this.)

Thanks,
Paul

> I know there are some implementations that do exactly this for audio. The
> OPAL implementation unfortunately is not designed to wait till the first RTP
> packet arrives before creating codecs, starting video grabbers, blah, blah,
> blah. It does it when the 200 OK arrives. So, OPAL gets around the ambiguity
> by immediately sending a re-INVITE selecting one of the codecs the remote
> answered with. We end up with:
>
>
>
> INVITE  H.264, H.263, H.261
>
> 200 OK  H.264, H.263
>
> Re-INVITE H.264
>
> 200 OK H.264
>
>
>
>
>
> Robert Jongbloed
>
> OPAL/OpenH323/PTLib Architect and Co-founder.
>
>
>
> From: Vineet Menon [mailto:mvineetme...@gmail.com]
> Sent: Tuesday, 6 March 2012 6:20 PM
> To: Sip-implementors@lists.cs.columbia.edu; opalvoip-devel
> Subject: [Opalvoip-devel] Capability negotiation control
>
>
>
> Hi,
>
>
>
> Say UAC sends H.261, 263,264 in offer, and now UAS wants to select one among
> them. UAS supports all three.
>
>
>
> Now, can UAS send all three codec it supports or it sends only the one
> preferred by it in the response?
>
>
>
>
>
> UAC -INVITE/H.261,H.263, H.264--->
> UAS
>
> UAC<---200 OK/
> ???  UAS
>
>
>
>
> Regards,
>
> Vineet Menon
>
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] multiple SDP messages in a single INVITE

[Paul Kyzivat]

On 2/29/12 4:33 AM, Vineet Menon wrote:
> Hi,
>
> I just read in a book about SIP that a single INVITE message can have
> multiple SDP payload...to be used for conferences.
> Why is multiple SDP needed in a conference scenario?
> Any ideas anyone??

This is news to me. What book?

RFC3959 defines the early-session content-disposition, for purposes of 
negotiating an early media session prior to answer that is distinct from 
the eventual session. In principle this can result in two SDP body parts 
in the same sip message. But I have never heard of this RFC having been 
implemented.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding Header argument

[Paul Kyzivat]

On 2/28/12 6:37 AM, satish agrawal wrote:
> Thanks Hughe/Dmitry
>
> for your prompt reply But my problem is regarding Diversion header
> In this case RFC 5806 say no white space is allowed After Colon(;).
> I have got the same.

I hope you realize that this draft was never approved as an RFC until 
recently when it was adopted as Historic simply to permanently record 
what had never been approved but had achieved some degree of defacto 
use. The text is much older than it appears - probably more than 10 
years. And because it was never agreed to as an RFC it never had careful 
scrutiny of its ABNF.

It is common practice that whitespace is allowed before each parameter. 
The manner of doing this was revamped in 3261. I suspect this draft was 
written before then when things were more sloppy.

You can try to argue with somebody that they are not in conformance with 
5806, and so get them to remove the whitespace. But I suspect you won't 
have a lot of luck with that.

Good luck,
Paul

> Thanks
> Satish
>
>
> On Tue, Feb 28, 2012 at 4:28 PM, Hugh 
> Waitewrote:
>
>> Hi,
>>
>> On 28/02/2012 10:09, satish agrawal wrote:
>>
>>> Hi
>>>
>>> Can any body Explain me in the Header after colon(;) space is allowed or
>>> not. If now then
>>> Where the RFC say as per my understanding space is not allowed. I am
>>> trying
>>> to find out the
>>> statement in RFC.
>>>
>>> Contact:*;*expires=3600
>>>
>>>   Whitespace around the semicolon ; in header parameters is allowed.
>> The ABNF in RFC3261 defines a contact as:
>>
>> Contact=  ("Contact" / "m" ) HCOLON
>>   ( STAR / (contact-param *(COMMA contact-param)))
>> contact-param  =  (name-addr / addr-spec) *(SEMI contact-params)
>> SEMI=  SWS ";" SWS
>>
>> where a contact can be followed by any number of "SEMI contact-params".
>> The definition of SEMI allows whitespace before and after the ';'.
>>
>> Regards,
>> Hugh
>>
>> --
>> Hugh Waite
>> Senior Design Engineer
>> Crocodile RCS Ltd.
>>
>>
>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding Header argument

[Paul Kyzivat]

On 2/28/12 5:09 AM, satish agrawal wrote:
> Hi
>
> Can any body Explain me in the Header after colon(;) space is allowed or
> not. If now then
> Where the RFC say as per my understanding space is not allowed. I am trying
> to find out the
> statement in RFC.

Read the ABNF. Its clearly specified there.

Regards,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] No SIP ID in Request URI in SUBSCRIBE message

[Paul Kyzivat]

On 2/27/12 11:06 PM, MohitSoni wrote:
> Hi Friends,
>
> Is the SUBSCRIBE message without SIP ID in Request URI valid?
>
> Actually, i have encountered with a SIP UA which sends SUBSCRIBE for
> Voice Mail notifications where it sends only IP Address in the Request
> URI and not sending the SIP ID for which it requires notifications.
>
> Is such SUBSCRIBE valid?

 From a sip protocol perspective it is valid.
It may or may not be valid for any particular event server.
I suspect that for most event servers it would not be.

It depends on whether that URI identifies a "resource" at the receiving 
event server. An example where it might be valid would be when 
subscribing to the dialog event at basic sip phone.

For an event server that supports a number of different users, 
distinguished by the value of the user part of the URI, then it probably 
would not be valid.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding SDP answer in ACK

[Paul Kyzivat]

On 2/24/12 4:23 AM, Arun Yadav wrote:
> Hi Roshan,
>
> It is perfectly OK for ACK to contain all the codec. In those scenario's
> both the UA's
>
> will select the first codec as the negotiated codec..

It is not required that they will use the first codec.
Multiple codecs may be used. A common example of this is when 
telephone-events is one of the codecs.

If you require that only a single codec be used, then you should make 
another offer, including only the one you want out of those agreed by 
the first offer.

Thanks,
Paul

> Thx,
>
> --Arun.
>
> --- *Original Message* ---
>
> *Sender* :
> sip-implementors-requ...@lists.cs.columbia.edu
>
> *Date* : Feb 24, 2012 00:35 (GMT+09:00)
>
> *Title* : Sip-implementors Digest, Vol 107, Issue 7
>
> Send Sip-implementors mailing list submissions to
> sip-implementors@lists.cs.columbia.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> or, via email, send a message with subject or body 'help' to
> sip-implementors-requ...@lists.cs.columbia.edu
>
> You can reach the person managing the list at
> sip-implementors-ow...@lists.cs.columbia.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Sip-implementors digest..."
>
>
> Today's Topics:
>
> 1. Re: Expected behavior for an INVITE sent without an offer
> (I?aki Baz Castillo)
> 2. Re: Expected behavior for an INVITE sent without an offer
> (Kevin P. Fleming)
> 3. Re: Expected behavior for an INVITE sent without an offer
> (Paul Kyzivat)
> 4. Re: Expected behavior for an INVITE sent without an offer
> (I?aki Baz Castillo)
> 5. Re: Regarding simultaneous Sessiontimernegotiations
> (OKUMURA Shinji)
> 6. Regarding SDP answer in ACK (Roshan nampeli)
>
>
> --
>
> Message: 1
> Date: Wed, 22 Feb 2012 23:11:21 +0100
> From: I?aki Baz Castillo
> Subject: Re: [Sip-implementors] Expected behavior for an INVITE sent
> without an offer
> To: Paul Kyzivat
> Cc: "sip-implementors@lists.cs.columbia.edu"
> , Brett Tate
>
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> 2012/2/22 Paul Kyzivat :
>  > If I was in the position of needing to construct a temporary offer, with
>  > no ability to handle media myself, and no knowledge of what the caller
>  > might be looking for or what is likely to be offered later, I would be
>  > inclined to offer audio with G.711 and a black holed IPv4 media address.
>  > Or maybe I would offer both audio and video and a whole bunch of codecs,
>  > still with black holed IPv4 address. But if possible it would be better
>  > to tailor the offer to the sorts of capabilities that will be offered
> later.
>
> And all of this makes the requirement of an SDP offer in the first 1XX
> response really a pain, am I wrong?
>
> BTW, what about if a SIP proxy/server receives an INVITE with no SDP
> offer and "Require: 100rel" and the SIP proxy/server wants to reply a
> 181 "Call Is Being Forwarded" or 182 "Queued" before ruting the call
> to the appropriate destination (imagine an specific SIP application
> server for an incoming call-center)? why should such a SIP
> server/proxy include an SDP offer in the 181/182 response? It makes no
> sense at all, and hence the requirement within RFC 3262 is wrong
> (IMHO).
>
> Maybe this annoying requirement is inheritance from RFC 3261 in which
> is stated that "the first reliable response to an INVITE MUST contain
> an SDP answer/offer (depending on the presence of SDP offer in the
> INVITE or not)?
>
> Regards.
>
> --
> I?aki Baz Castillo
>
>
>
>
> ------
>
> Message: 2
> Date: Wed, 22 Feb 2012 16:59:14 -0600
> From: "Kevin P. Fleming"
> Subject: Re: [Sip-implementors] Expected behavior for an INVITE sent
> without an offer
> To: sip-implementors@lists.cs.columbia.edu
> Message-ID: <4f457342.6060...@digium.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 02/22/2012 04:11 PM, I?aki Baz Castillo wrote:
>  > 2012/2/22 Paul Kyzivat:
>  >> If I was in the position of needing to construct a temporary offer, with
>  >> no ability to handle media myself, and no knowledge of what the caller
>  >> might be looking for or what is likely to be offered later, I would be
>  >> inclined to offer audio with G.711 and a black holed IPv4 media address.
>  >> Or maybe I would offer both audio and video and a whole bunc

Re: [Sip-implementors] Regarding SDP answer in ACK

[Paul Kyzivat]

On 2/23/12 8:09 AM, Roshan nampeli wrote:
> Hello,
>
> In the SIP sdp offer/answer scenario suppose  A sends INVITE without SDP to B.
> B then replies with all the codecs it supports (say 0,8,4,18).
> Then is it proper for A to reply in ACK with all codecs (say 0,8,18,4) ?

YES.

That means that any of them may be used during the course of the session.

This has nothing at all to do with the answer being in the ACK. It 
applies to all o/a cases.

Thanks,
Paul

> A---INVITE(no sdp)-->  B
> A<100 trying--B
> A<180ringing-B
> A<---200Ok(0,8,4,18)B
> A---ACK(0,8,18,4)--->B
>
> Thanks in advance,
> Roshan.
>
>
> --
> This e-mail and its attachments contain confidential information from HUAWEI, 
> which is intended only for the person or entity whose address is listed 
> above. Any use of the information contained herein in any way (including, but 
> not limited to, total or partial disclosure, reproduction, or dissemination) 
> by persons other than the intended recipient(s) is prohibited. If you receive 
> this e-mail in error, please notify the sender by phone or email immediately 
> and delete it!
> --
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Expected behavior for an INVITE sent without an offer

[Paul Kyzivat]

On 2/22/12 5:59 PM, Kevin P. Fleming wrote:
> On 02/22/2012 04:11 PM, Iñaki Baz Castillo wrote:
>> 2012/2/22 Paul Kyzivat:
>>> If I was in the position of needing to construct a temporary offer, with
>>> no ability to handle media myself, and no knowledge of what the caller
>>> might be looking for or what is likely to be offered later, I would be
>>> inclined to offer audio with G.711 and a black holed IPv4 media address.
>>> Or maybe I would offer both audio and video and a whole bunch of codecs,
>>> still with black holed IPv4 address. But if possible it would be better
>>> to tailor the offer to the sorts of capabilities that will be offered later.
>>
>> And all of this makes the requirement of an SDP offer in the first 1XX
>> response really a pain, am I wrong?
>>
>> BTW, what about if a SIP proxy/server receives an INVITE with no SDP
>> offer and "Require: 100rel" and the SIP proxy/server wants to reply a
>> 181 "Call Is Being Forwarded" or 182 "Queued" before ruting the call
>> to the appropriate destination (imagine an specific SIP application
>> server for an incoming call-center)? why should such a SIP
>> server/proxy include an SDP offer in the 181/182 response? It makes no
>> sense at all, and hence the requirement within RFC 3262 is wrong
>> (IMHO).
>>
>> Maybe this annoying requirement is inheritance from RFC 3261 in which
>> is stated that "the first reliable response to an INVITE MUST contain
>> an SDP answer/offer (depending on the presence of SDP offer in the
>> INVITE or not)?
>
> Yes, that's exactly where it comes from. The usage of 100rel/PRACK turns
> that 181/182 response into a 'reliable response'.

AFAIK that language came before my time.
If we had it to do over, I suspect that requirement would be relaxed.
But we are where we are, and changing it would probably cause more grief 
than living with it. (The problem being backward compatibility with any 
implementations that depend upon this.)

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Expected behavior for an INVITE sent without an offer

[Paul Kyzivat]

On 2/22/12 4:30 PM, Brett Tate wrote:
>> I do not know the reasoning behind this requirement.
>> Many would find it convenient if it wasn't there. But
>> the gist of the discussion was that relaxing this
>> requirement after its been along is more trouble than
>> its worth. Its really not that hard to come up with
>> some sort of offer.
>
> It is easy to build an offer; it is the potential side effects that may not 
> be desirable.  Hopefully any device sending an offer-less INVITE and 
> requiring 100rel also supports UPDATE, forking proxies, and won't cancel the 
> INVITE if it doesn't like the required offer.
>
> For instance if a proxy does not support media and wants to return a 181 (or 
> another 1xx potentially known or unknown by UAC), hopefully the UAC won't 
> cancel the INVITE if receives an offer with IP6 .invalid connection address 
> and foo media.
>

If I was in the position of needing to construct a temporary offer, with 
no ability to handle media myself, and no knowledge of what the caller 
might be looking for or what is likely to be offered later, I would be 
inclined to offer audio with G.711 and a black holed IPv4 media address. 
Or maybe I would offer both audio and video and a whole bunch of codecs, 
still with black holed IPv4 address. But if possible it would be better 
to tailor the offer to the sorts of capabilities that will be offered later.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding simultaneous Session timernegotiations

[Paul Kyzivat]

On 2/22/12 5:54 AM, OKUMURA Shinji wrote:
> Hi Paul,
>
> I think that the following rule should be applied to Session-Expires.
>
> RFC3311/5.1 Sending an UPDATE
> If a UA
> uses an UPDATE request or response to modify the remote target while
> an INVITE transaction is in progress, and it is a UAS for that INVITE
> transaction, it MUST place the same value into the Contact header
> field of the 2xx to the INVITE that it placed into the UPDATE request
> or response.
>
>
> But a particular crossing case is not avoidable as yet.
>
> A   B
> |   |
> |re-INV |
> |-->|
> |18x-rel|
>   b1|<--|b1
> |2xx|
> |   /---|b2/s1
> |UPD   /|
> |=/>|
> |/  2xx(UPD)|
>b3/s2|<==/===|b3/s2
> |  /|
>  * b2/s1|</ |
> |ACK|
> |-->|
> |   |
>
> UA-A may need a new UPDATE or re-INVITE to confirm a common view
> of Session-Expires.

In this case, only B has enough info to realize there is a problem.
So if it discovers that there is an ambiguity it would need to initiate 
another session timer refresh.

Thanks,
Paul

> Regards,
> Shinji.
>
> Paul Kyzivat
> Mon, 20 Feb 2012 12:24:08 -0500
>> On 2/20/12 8:43 AM, Brett Tate wrote:
>>>> The RFC 4028 allows 2 simultaneous session timer
>>>> negotiations i.e with Re-Invite and Update. So the following
>>>> combinations are possible for session refresh request.
>>>
>>> 
>>>
>>>> The session timers (session interval and session expires)
>>>> will be started based on the session expires header values
>>>> in the 2xx response of refresh request.
>>>>
>>>> The cross over of the response messages is also possible
>>>> (Response for the first refresh request received after the
>>>> response for the second refresh request).
>>>
>>> Correct.  As discussed within the following and related threads,
>>> this is one of the potential SIP race conditions.
>>>
>>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-October/025881.html
>>>
>>>
>>>> The session expires in the 2xx response must be validated
>>>> by the stack as per the rules defied in RFC4028.
>>>>
>>>> What would be the most elegant way of handling such scenarios:
>>>
>>> Assume that the latest received/sent 2xx is the most accurate.
>>> If overly concerned that the race condition may cause the session
>>> to not be refreshed in time, you can do something like pick the
>>> lowest interval among the choices and act as the refresher.
>>>
>>> If you want to see the issue fixed or addressed as a BCP, you
>>> might raise the issue within the dispatch or sipcore working
>>> groups to see if anyone else wants this and similar race condition
>>> ambiguities resolved.  If I recall correctly, this was not one of
>>> the issues fully addressed by RFC 6141 or RFC 5407.
>>
>> I'm generally supportive of working out all the ambiguities in the sip
>> specs. But some cases are so minor and theoretical that they don't
>> warrant the work required to work out and publish the clarification. I'd
>> be interested in hearing descriptions of instances of this problem "in
>> the wild".
>>
>> It would be appropriate to file an errata against the draft. That will
>> mean that the issue will at least be addressed if/when the draft is
>> revised in the future.
>>
>> (BTW, Its my impression that session timer is vastly over-used. There is
>> no need for two UAs to use session timer to monitor the session between
>> them: each may send an in-dialog request at any time to verify it. The
>> primary value of session timer if for record-routed proxies.)
>>
>>  Thanks,
>>  Paul
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] DTMF SIP INFO or InBand- how to recognize by SDP negotiation

[Paul Kyzivat]

On 2/22/12 6:51 AM, vivek.ba...@matrixcomsec.com wrote:
> Hi,
>
> I am struggling to find out this from long time, however have seen
> some implementation as follows;
>
> 1. First of all, you can't know whether remote end has a capability to
> detect DTMF in Inband.
> 2. For SIP INFO, your device can consider that remote end supports SIP
> INFO if received in Allow header. If received, it's upto your device
> whether to generate DTMF in Inband or SIP INFO.
> 3. You can't always fallback to SIP INFO if RFC 2833 negotiation
> fails. Remote end must be capable of detecting DTMF in SIP INFO and
> this would be known only if INFO is received in Allow header. If RFC
> 2833 negotiation fails and remote end hasn't capability of detecting
> DTMF in SIP INFO, you haven't any other choice than sending DTMF in
> Inband :)
>
> Different people may have different views but that is what implemented
> in most of the live products.

The problem is more difficult than you have described.
There is no official standardized info package for DTMF, though there is 
a defacto one that is used a number of places. Then there is the KPML 
event package. And Cisco also has a different event package that they 
use with unsolicited NOTIFYs without any subscription, which of course 
is entirely nonconforming.

Cisco uses some proprietary indications with some heuristics to decide 
which to use. But I don't have the details. And other companies must 
also have their own techniques.

Good Luck,
Paul

> Best Regards,
> Vivek Batra
>
> Quoting "Manoj Priyankara":
>
>> Folks,
>>
>> I wonder how the offerer recognizes whether a particular SIP end point
>> supports in-band DTMF or SIP INFO by negotiating SDP? SIP INFO is assumed
>> when RFC2833 negotiation fails but how exactly we know whether the endpoint
>> supports SIP INFO not In Band?
>>
>> Cheers!
>> Manoj
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>
>
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Expected behavior for an INVITE sent without an offer

[Paul Kyzivat]

Thanks for all the references Brett!
I don't know how you manage to dredge them all up.

I haven't bothered to read through them all now - sorry.
But the requirement for an offer in the first reliable response was 
debated at length a *long* time ago. (I recall a live discussion at some 
meeting, with Rohan taking the active role.)

I do not know the reasoning behind this requirement. Many would find it 
convenient if it wasn't there. But the gist of the discussion was that 
relaxing this requirement after its been along is more trouble than its 
worth. Its really not that hard to come up with some sort of offer.

Thanks,
Paul

On 2/22/12 9:29 AM, Brett Tate wrote:
> Issues with RFC 3262 have been raised over the years including the long 2006 
> SIP Tread "The Problem with PRACK".
>
> http://www.ietf.org/mail-archive/web/sip/current/msg13221.html
>
> Some of them have been addressed by RFC 6337, RFC 6141, and RFC 6228.  
> However as RFC 6337 indicates, some issues still exist.
>
> I don't recall if the potential deprecation of RFC 3262's requirement of 
> offer within 18x was one of the things proposed within the above thread; 
> however it was the topic of the following thread.
>
> http://www.ietf.org/mail-archive/web/sipping/current/msg17210.html
>
> If you are motivated to do so, raise the issues with RFC 3262 within SIPCORE 
> or DISPATCH to see if there is any current interest in an rfc3262bis.
>
> The following are some other the old RFC 3262 threads which might help 
> present some of reasons an rfc3262bis might be useful.
>
> http://www.ietf.org/mail-archive/web/sip/current/msg13240.html
>
> http://www.ietf.org/mail-archive/web/sipping/current/msg15146.html
>
>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
>> Castillo
>> Sent: Wednesday, February 22, 2012 8:00 AM
>> To: Kevin P. Fleming
>> Cc: sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Expected behavior for an INVITE sent
>> without an offer
>>
>> 2012/2/22 Kevin P. Fleming:
>>> Well, this scenario is not very realistic anyway, because as others
>> have
>>> pointed out, "Require: 100rel" in an INVITE is a fairly bad idea to
>>> begin with.
>>
>> "Require: 100rel" is a bad idea for anything, right. And also the
>> whole PRACK specification. A much more easier approach to get "the
>> same" is just to retransmit the 1XX responses every X seconds. That's
>> advised by other SIP related specifications, i.e: ICE usage. PRACK
>> adds lot of complexity (a spec coming from 3GPP world, of course).
>>
>> --
>> Iñaki Baz Castillo
>> 
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Expected behavior for an INVITE sent without an offer

[Paul Kyzivat]

On 2/21/12 4:12 PM, Iñaki Baz Castillo wrote:
> 2012/2/21 Kumar, Hemanth:
>> You probably missed the point that INVITE is sent with Require 100rel.
>
>> So 18x should contain SDP.
>
> That's not true.

Iñaki,

If the invite is offerless, and contains Require:100rel, then the first 
provisional must be reliable, and the first reliable response must 
contain an offer.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Expected behavior for an INVITE sent without an offer

[Paul Kyzivat]

On 2/21/12 11:22 AM, Kumar, Hemanth wrote:
> Hi Sai,
>
> You probably missed the point that INVITE is sent with Require 100rel.
> So 18x should contain SDP.
>
> My question is related expected behavior due misbehaving endpoint not
> sending SDP in 18x.

I already responded to this once.

Why are you *requiring* 100rel? (Rather than just supporting it.)
Its not common behavior. And its inviting problems when interacting with 
something that doesn't expect this.

But still UE2 is misbehaving, and ought to be fixed.

Thanks,
Paul

> Regards
>
> Hemanth
>
> *From:*Sairam POKKUNURI [mailto:sair...@ipinfusion.com]
> *Sent:* Monday, January 09, 2012 10:22 AM
> *To:* Kumar, Hemanth
> *Cc:* sip-implementors@lists.cs.columbia.edu; Paul Kyzivat
> *Subject:* Re: [Sip-implementors] Expected behavior for an INVITE sent
> without an offer
>
> Hi
>
> Invite without SDP is initiation of late media.
>
> In that case 18x response can have a complete offer or 200 OK can have
> an offer with ack containing answer.
>
> More details are mentioned in RFC 3264 and 3261
>
> Reg
>
> Sai
>
> On Wed, Jan 4, 2012 at 8:39 PM, Kumar, Hemanth  <mailto:hku...@sonusnet.com>> wrote:
>
> Hi,
>
> What should be the behavior of UAC when an INVITE is sent without offer
> and Require 100rel and it receives non-reliable/reliable 18x response
> without SDP?
>
> Should the transaction be terminated by sending CANCEL?
>
> The same scenario was given as comment which has not been addressed in
> offer/answer draft-ietf-sipping-sip-offeranswer-03
>
> http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-sip-offeranswer-03-seth.txt
>
> " 3. Section 1.1 :
> Comment :- We should define the behavior for a UAC which sends out an
> INVITE without SDP and receives the first non-failure reliable response
> without an Offer, due to the UAS not conforming to the draft. As this
> being an open point can lead to multiple different implementations. Does
> the UAC clear the call or send a PRACK and wait for the offer in
> subsequent reliable responses."
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
>
> --
> With Regards
> Sairam
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding simultaneous Session timer negotiations

[Paul Kyzivat]

On 2/20/12 8:43 AM, Brett Tate wrote:
>> The RFC 4028 allows 2 simultaneous session timer
>> negotiations i.e with Re-Invite and Update. So the following
>> combinations are possible for session refresh request.
>
> 
>
>> The session timers (session interval and session expires)
>> will be started based on the session expires header values
>> in the 2xx response of refresh request.
>>
>> The cross over of the response messages is also possible
>> (Response for the first refresh request received after the
>> response for the second refresh request).
>
> Correct.  As discussed within the following and related threads, this is one 
> of the potential SIP race conditions.
>
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-October/025881.html
>
>
>> The session expires in the 2xx response must be validated
>> by the stack as per the rules defied in RFC4028.
>>
>> What would be the most elegant way of handling such scenarios:
>
> Assume that the latest received/sent 2xx is the most accurate.  If overly 
> concerned that the race condition may cause the session to not be refreshed 
> in time, you can do something like pick the lowest interval among the choices 
> and act as the refresher.
>
> If you want to see the issue fixed or addressed as a BCP, you might raise the 
> issue within the dispatch or sipcore working groups to see if anyone else 
> wants this and similar race condition ambiguities resolved.  If I recall 
> correctly, this was not one of the issues fully addressed by RFC 6141 or RFC 
> 5407.

I'm generally supportive of working out all the ambiguities in the sip 
specs. But some cases are so minor and theoretical that they don't 
warrant the work required to work out and publish the clarification. I'd 
be interested in hearing descriptions of instances of this problem "in 
the wild".

It would be appropriate to file an errata against the draft. That will 
mean that the issue will at least be addressed if/when the draft is 
revised in the future.

(BTW, Its my impression that session timer is vastly over-used. There is 
no need for two UAs to use session timer to monitor the session between 
them: each may send an in-dialog request at any time to verify it. The 
primary value of session timer if for record-routed proxies.)

Thanks,
Paul


___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] max number of routes in INVITE

[Paul Kyzivat]

On 2/12/12 11:54 AM, radhakrishnan jayachandran wrote:
> How many number of routes can I have at maximum in the INVITE?
> Suppose, If I have an Application Server (chains of application server and
> all B2BUAs) connected to the S-CSCF, and the INVITE request goes through a
> complex routing mechanism, how much routes can I traverse? (to optimise the
> overall usage of Application Sequencing).
> Can I have infinite number of routes or Does the standard restricts us to
> limit to a maximum of "n" number of routes?

SIP has no limits of this sort.

Perhaps IMS has some, but you will have to check the IMS specs for that.

(I'm not certain what you have in mind regarding multiple routes and 
complex routing. What comes to my mind is sip-level forking of requests, 
or else DNS-level alternative addresses. Or are you concerned with 
*long* routes, due to visits from the S-CSCF to many application 
servers? But it doesn't really matter - the answer is the same.)

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Authorization of incoming call

[Paul Kyzivat]

What is the real concern here?
Why would you care if the caller has registered? SIP does not require 
registration to send requests.

I guess you either are concerned that the caller is somehow authorized 
to call you, or call anybody, or else you are concerned with whether you 
can trust the identity of the caller as specified by the incoming request.

Whether the caller is authorized to send invites is really none of your 
business. If the invite was sent, and reached you, then presumably the 
caller had as much authorization as it needed.

Whether the caller is authorized to call *you* is your problem. If you 
are concerned about the call reaching you via your proxy or not, then it 
seems you want to delegate some of the authorization of callers to your 
proxy. Doing so has to be an agreement between you and your proxy. That 
agreement will have some responsibilities for each of you. Those are not 
standardized - you will have to consult the documentation for the proxy 
you use. If that is your intent, then you probably want to reject calls 
that don't arrive with the proxy as the prior hop (in Via). If not, in 
theory you could return a 305 response, telling the caller to try again 
via the proxy. But the exact use of 305 is underspecified so that's 
unlikely to work well.

Whether you can trust the identity of the caller depends on the 
environment in which you are embedded. An infrastructure such as 
3gpp/IMS has a number of extra mechanisms to control access, and then 
depends on transitive trust. If you are registered within IMS and 
receive a request in accord with that you can, within limits, trust the 
ID provided via P-Asserted-Identity. Enterprise SIP networks, such as 
"SIP PBXs" also typically control things and depend on transitive trust.

Outside such environments it gets harder. SIP Identity (RFC 4474) is 
intended for this, but isn't implemented much. You could of course 
challenge the caller using digest authentication, but that would require 
that you have a password for every caller, which isn't very likely.

Absent that, you should probably consider the identity of the caller (in 
the From header of the invite) as suspect. Whether you want to answer 
such calls is up to you, for general telephony I think most would want 
to at least alert and let the user decide whether to answer.

Thanks,
Paul

On 1/12/12 3:56 AM, Vineet Menon wrote:
> Hi,
>
> Again, you can force route all calls thru the proxy so that calls
> will always be routed thru the proxy. So that, a session hijacking can be
> avoided.
>
> In addition to this, I wanted to clarify whether the use of proxy avoid
> another user from calling your UA without registering to proxy ? eg. using
> IP dialing...
> How can this be avoided? I am peculiarly concerned because this is like
> some malicious user is using your infrastructure for his own purpose. I
> believe SIP in its core cannot do this!!
>
> Regards,
>
> Vineet Menon
>
>
>
>
> On 11 January 2012 19:41, Kevin P. Fleming  wrote:
>
>> On 01/11/2012 07:11 AM, Sandro wrote:
>>> Hello all.
>>>
>>> I have a theoretical question about call admitting and security.
>>>
>>> Let's say we have two clients A&B (phones or softphones) and a
>>> proxy/registrar.
>>> Clients register themselves on the registrar with authentication (http
>>> digest).
>>> This is, i think, the most normal scenario.
>>>
>>> Proxy authenticates incoming (from the clients) calls, this means invite
>>> messages, with the same registrar credentials, and this gives it a
>> certain
>>> degree of security.
>>>
>>> What happens for clients?
>>> I mean, how can a client "authorize/authenticate" a call coming from the
>>> proxy and become sure it's is *really* coming from its proxy?
>>>
>>> Let's say for example that a "C" malicious client/proxy is sending
>> INVITEs
>>> to A.
>>> How can A recognize that these INVITEs are not related to the REGISTER
>>> "session" to the proxy?
>>
>> There is no perfect method to do this, but one very common method is for
>> the UA that REGISTERs to include a randomly-generated token in the
>> Contact URI that it supplies to the registrar; incoming INVITEs
>> generated by UAs that obtained the Contact URI from that registrar will
>> then include that token, and the receiving UA can 'trust' that the
>> INVITE was generated by a UA that was authorized by the registrar to do so.
>>
>> This can easily be sniffed by a third party if the SIP signaling is not
>> secured, of course.
>>
>> --
>> Kevin P. Fleming
>> Digium, Inc. | Director of Software Technologies
>> Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at www.digium.com&  www.asterisk.org
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> ___

Re: [Sip-implementors] Expected UAC behavior when a reliable/non-reliable 18x without SDP is recieved for an INVITE sent without an offer and require 100 rel

[Paul Kyzivat]

UE2 is operating in a non-conforming manner.

In this (and most) cases, the behavior when dealing with a 
non-conforming message is not defined. Its up to you to decide what you 
want to do. You can experiment with what works best for you. There is no 
guarantee that anything you do will work *well*, or in a consistent way.

The main thing you should do is contact the vendor of the offending 
device, and ask them to fix their device.

Thanks,
Paul

On 1/6/12 3:22 AM, Kumar, Hemanth wrote:
> Hi All,
> This is a B2BUA scenario.
> This issue is as shown below
> UE1 - INVITE [no SDP, Require:100 Rel]  > B2BUA ---
> INVITE [no SDP, Require:100 Rel] ---> UE2
> B2BUA *<--- 183 [no SDP] - UE2 *
> When an INVITE is sent with require 100rel and without an offer,
> misbehaving UE2 sends 18x without SDP.
> RFC 6337 does not define the behavior of UAC in this case.
> There could be 2 possible solutions:
> 1. Tear down the call by sending CANCEL on egress leg and 420 Bad
> extension response on ingress leg as shown below
> UE1 - INVITE [no SDP, Require:100 Rel]  > B2BUA---
> INVITE [no SDP, Require:100 Rel] ---> UE2
> UE1 <- 420 Bad extension --
> B2BUA<--- 183 [no SDP] -- UE2
> B2BUA --- CANCEL --> UE2
> 2. Ignore 18x received and wait for reliable response containing SDP on
> the egress leg. On receiving the response, send 18x reliably with SDP
> followed by 200 OK with the same SDP on the ingress leg. This ensures
> backward compatability.
> UE1 - INVITE [no SDP, Require:100 Rel]  > B2BUA ---
> INVITE [no SDP, Require:100 Rel] ---> UE2
> B2BUA <-- 183 [no SDP] -- UE2
> UE1 <- 183 [with SDP] - B2BUA
> <--- 200 [with SDP] -- UE2
> UE1 <- 200 [with SDP] - B2BUA
> I would appreciate if you could share your comments on both the
> solutions and propose alternate solution if any.
> Regards
> Hemanth
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Kumar, Hemanth
> Sent: Wednesday, January 04, 2012 8:39 PM
> To: sip-implementors@lists.cs.columbia.edu
> Cc: Paul Kyzivat
> Subject: [Sip-implementors] Expected behavior for an INVITE sent without
> an offer
> Hi,
> What should be the behavior of UAC when an INVITE is sent without offer
> and Require 100rel and it receives non-reliable/reliable 18x response
> without SDP?
> Should the transaction be terminated by sending CANCEL?
> The same scenario was given as comment which has not been addressed in
> offer/answer draft-ietf-sipping-sip-offeranswer-03
> http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-sip-offeranswer-03-seth.txt
> " 3. Section 1.1 :
> Comment :- We should define the behavior for a UAC which sends out an
> INVITE without SDP and receives the first non-failure reliable response
> without an Offer, due to the UAS not conforming to the draft. As this
> being an open point can lead to multiple different implementations. Does
> the UAC clear the call or send a PRACK and wait for the offer in
> subsequent reliable responses."
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Reduce the time to send UPDATE message in SIP call

[Paul Kyzivat]

As already asked, are you presuming use of Session Timer to drive the
sending of the UPDATEs?

Assuming A and B are both UAs, not proxies, then there is no need to use
session timer to negotiate keep-alives. (Session Timer is primarily for
the benefit of proxies in the route.) A UA may send signaling any time
it wants. If UA A has some reason to suspect that connectivity has been
lost, it can send an UPDATE to confirm its suspicion. There is no
particular timer associated with that. Of course if it does so too often
it may degrade performance. It may suspect lack of connectivity due to
lack of media, or whatever.)

Thanks,
Paul

On 12/27/11 11:34 PM, Verma, Salil (NSN - IN/Gurgaon) wrote:
> Hi,
> 
> 
> 
> If there is any problem that ( A-Node) cannot receive BYE message from 
> partner exchange, A-Node will be waiting about 15 minutes, then A-Node will 
> send UPDATE message and the partner will send 481 message with 
> Call/Transaction Doesn't Exist. After that, A-Node will clear call.
> 
> 
> 
> Can we reduce the duration time to send UPDATE message to around 1-2 minutes? 
> It means that during call converstion, every 1-2 minutes A-Node will send 
> UPDATE message to check call status.
> 
> 
> 
> Thanks,
> Best Regards
> sAlil veRmA
> Customer Service Engineer ( Care Team )
> NCS : sip:  salil.ve...@nsn.com
> +91 9958298813
> 
> 
> 
> 
> 
> 
> 
> ♥   Life can give us a number of beautiful persons,
> But only true persons can give us a beautiful life..   ♥
> 
> 
> 
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] History-Info

[Paul Kyzivat]

On 12/22/11 1:14 AM, Johnson, Michael A wrote:
> I am seeking clarification on the History-Info RFC 4424
>
> In a transit scenario, an incoming call that is immediately redirected to 
> another party, I am getting rejected based on the History-Info field.
> This is only where there is no A-party identity provided on the initial call. 
> On the outgoing invite I send the from address as 'anonymous@ 
> as.abc.company.com" but include the P-Preferred identity for authentication 
> purposes.
> My ISP, however will not accept the call based on the fact that the domain in 
> the History-Info is the system IP, and does not match the Server Line/Port on 
> the initial incoming invite.
> To: "712345678 712345678" 712345...@endcustomer.com.au;url-cookie=VNCHHA1-b6bpj6434lp57>
>
> I do not find anything in the RFC that clearly seems to specify how this 
> should work.

You should know that 4244 will soon be superseded by 
http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-06.txt. While you 
can't expect your ISP to support that yet, it at least gives an 
indication of direction and clarification of intent.

But as Dale said, there was and is no intent to specify that servers 
should reject requests based on what they do/don't find in H-I. IMO a 
server that fails a call because it doesn't like your H-I is a *bad* 
server that should be publicly chastised. However such behavior is not 
"non-compliant".

If you can't choose a new ISP, then tell your ISP that they are being 
stupid and out to lighten up.

Thanks,
Paul

>
> 2011-12-21  07:20:20  STS->Network  SSP   Level = 3  
> Unique ID = 0
> INVITE 
> sip:0438xxx...@as.abc.company.com:5060;transport=udp
>   SIP/2.0
> Via: SIP/2.0/UDP 10.XX.YY.ZZ:5060;branch=z9hG4bK2724966256-92170064
> Route:>
> Max-Forwards: 25
> Authorization: Digest 
> username="NXXX",realm="client.com",nonce="BroadWorksXgwfexftkTs4w3nmBW",uri="sip:0438xxx...@as.abc.company.com:5060",response="64d5cfk3af388d6016e49ee004a2ab78",algorithm=MD5,cnonce="b3c85b02a0971594cdd55d56653abd6e713a9d8dd7162f62f8a843462fca9350",qop=auth,nc=0001
> Allow: 
> INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
> Supported: timer,replaces
> From: "Anonymous";tag=0_2724896256-92170062
> To:>
> Call-ID: 
> 2724896256-92170...@10.xx.yy.zz
> CSeq: 3 INVITE
> Min-SE: 90
> Session-Expires: 90;Refresher=uas
> Contact: 
> "Anonymous">
> P-Preferred-Identity: "712345600"
> Diversion: 
> "Spare">;reason=unconditional;counter=1
> History-Info: 
> "Spare">;index=1,>;index=1.1
> User-Agent: Mitel-3300-ICP 10.2.1.13
> Content-Type: application/sdp
> Content-Length: 357
>
> Thanks.
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Route-Record

[Paul Kyzivat]

On 12/21/11 3:09 AM, Saul Ibarra Corretge wrote:
> Hi,
>
> On Dec 21, 2011, at 8:00 AM, William Scott wrote:
>
>> On 21 December 2011 17:10, Alex Balashov  wrote:
>>> Is your concern about the two RR headers, or the double lr parameter?
>>
>> The double lr parameter.
>>
>> When my ATA sends the double lr to a VSP using Asterisk the call continues.
>>
>> When it sends it to a VSP using "Sippy" (as seen in User-Agent: and
>> Server:) I fail to receive a ACK for my 200 OK. Multiple 200 OK are
>> sent then finally a BYE message.
>>
>
> As a general rule, the server should be gentle in what it accepts ;-)

+1

The repeated 'lr' is erroneous.

There are no particular rules for what to do when receiving something 
erroneous, especially if its in a response. I don't fully follow exactly 
what happened in the case that failed. But its not ok to deny the ACK 
because of trouble with the 200.

Presumably the bad R-R is being added to the request by some middle box, 
then returned in the response. Anything that detects the R-R as being 
malformed in the request has some alternatives:
- preserve it as-is
- canonicalize it: remove one of the 'lr's
- return an error code - probably 400

Middleboxes that detect the R-R as being malformed in the response have 
fewer options:
- preserve it as-is
- canonizalize it: remove one of the 'lr's

If the malformed R-R makes it back in a 2xx response to the UAC, then 
the UAC can:
- preserve it as-is in the route set
- canonicalize it in the route set
- ACK the response and then kill the call with BYE.
   However, the BYE must follow the route set, so it can't avoid making
   one of the above choices first.

If the UAC preserves the double 'lr' in the route set, then in-dialog 
requests will have double lr in the Route header. That will set off a 
similar set of issues in handling of Route.

The thing that is most likely to work well is to canonicalize by 
removing the extra 'lr'. Some implementations may find that this falls 
out automatically. For others it may be unnatural / difficult.

Ultimately the right thing is to get the ATA fixed.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] How to transfer an existing subscription from one RLS server to another

[Paul Kyzivat]

On 12/8/11 8:16 AM, Joegen Baclor wrote:
> On 12/08/2011 06:47 AM, Worley, Dale R (Dale) wrote:
>>> From: Joegen Baclor [jbac...@ezuce.com]
>>>
>>> I am implementing an RLS service that shares load via DNS/SRV records.
>>> Let us say I have 2 RLS servers sharing the load equally for 200
>>> subscribers.  In an ideal setting, each would service 100 subscribers
>>> each.  In the moment one goes down, subscribers from the other server
>>> spills over to the other server.  So at one point all 200 subscribers
>>> are now subscribed to a single server.  When the node that went down
>>> previously goes up, I like to be able to bring back load sharing between
>>> the two nodes.   There seems to be no obvious mechanism to do this in
>>> SIP.  I would appreciate some insights and suggestions.
>> There are at least two approaches.  One approach is to have the RLS
>> servers split the load on a request-by-request basis, so that they are
>> jointly the notifyer UA for the subscriptions.  This requires that
>> they share all of the subscription state.  When a server sends the 200
>> to a subscription-initiating SUBSCRIBE, it inserts a Record-Route
>> containing a DNS name that resolves to both servers.  Thus, each
>> SUBSCRIBE within the dialogs goes randomly to either of the servers,
>> and the server that receives the SUBSCRIBE replicates the updated
>> subscription state to the other server.  For any NOTIFY to be
>> generated, the servers have to decide which of them is to send it, and
>> update their mutually-held subscription state to record that fact.
>> This would be rather high-overhead to implement.
>>
>> Another approach is to have both servers serve the same data, but any
>> single subscription is terminated on only one server as notifying UA.
>> If one server goes down, when a UA whose subscription is notified by
>> that server decides to re-SUBSCRIBE, it discovers the server is down.
>> The UA reestablishes a new subscription, which goes to the other
>> server.  When the down server comes up again, the load is unbalanced.
>> The overloaded server could force some subscriptions to be
>> reestablished by sending "NOTIFY/Subscription-State: terminated".  But
>> I don't think there's any point in doing that -- of necessity, either
>> server must be able to handle the full load without degrading the
>> system.
>>
>> Dale
>>
>
> Thanks Dale.   I think you do have a good handle on this being the
> author of RLS in sipX.  I am actually contemplating on option 1 and
> simply have a static algorithm in the proxy to somehow control the
> balancing based on realtime load of each RLS server.  I am indeed
> tempted to resort to simply use the 3265's Notify with state
> "terminated" and hope that the UAC is compliant and re-establish the
> dialog but having to rely on "UAC's" compliance  almost always guaranty
> an interoperability issue.

If you are using DNS/SRV load balancing, then simply terminating the 
subscription and having the subscriber reissue it is sub-optimal. Since 
the load balancing is static, presumably half of the terminated 
subscriptions will come back to the server that terminated them. So you 
will end up only shifting 25% of the load to the recovered server.

You could do something extreme, like send a REFER/Replaces with 
method=SUBSCRIBE, using an address that prefers the server you want to 
transfer to. But the likelihood of that being supported by the 
subscriber is slim to none.

I'm inclined to agree with Dale thatyou just do nothing, and let it 
level out based on attrition.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Duplication of SIP Header

[Paul Kyzivat]

On 12/7/11 12:06 AM, Brez Borland wrote:
> On Tue, Dec 6, 2011 at 3:35 PM, Paul Kyzivat  <mailto:pkyzi...@alum.mit.edu>> wrote:
>
> The examples below look like some sort of conformance test, rather than
> cases that would actually be encountered in practice. If so, I suppose
> either you are implementing the tester and looking for what response to
> expect, or else you have failed a conformance test and are looking for
> an argument about why the tester is wrong.
>
> For the most part 3261 does not mandate behavior for non-conforming
> cases. So in general for the cases you describe almost any behavior
> would be ok. It then becomes a "quality of implementation" issue, not a
> conformance issue.
>
> Also, you have two kinds of cases below:
> - repetition of headers that are only permitted to occur once
>(e.g. To, From, Call-ID)
> - repetition of headers that can appear more than once, but in a
>form that makes little sense. (E.g. Via)
>
> In the former case, the recipient might notice the duplication and
> object to it. Or it might not notice, and just process one of the
> instances of the header. Either is ok.
>
> In the latter case, you need to look into the details. E.g. for Via, as
> long as the vias get cleaned up while routing the response, and the
> response gets where it should, then all is well.
>
>
> A very good reasoning. I also think such behaviour should not occur in
> SIP elements, even if restriction to do so is not described anywhere in
> the docs.

Well, repeating a header that is defined to appear at most once is a 
violation.

If you are referring to the Via case, I think it is very hard and not 
worth the trouble to identify all the stupid things that someone might 
do and ban them. There is a fine line between what is stupid and 
useless, and that which actually has significance in some implementation.

Why do you care what is in the via headers added by other elements? It 
really shouldn't be of interest to you, other than the top-most one that 
you must use to forward a response.

> I would respond with 400 where Reason-Phrase describing first
> encountered failure in the request (i.e. first duplicated header). I
> probably wouldn't bother about duplicated Via headers much, as these
> have to be dealt with by the upstream elements only. But other headers
> mentioned, are the concern of the downstream elements, and I wouldn't
> allow pass this junk through because, as Paul mentioned there, depending
> on the implementation the receiver might, or might not, process the
> request. And sending request downstream with the uncertainty of it being
> handled is beneficial for nobody, and is irresponsible at the very least.

If you want to go to the trouble of detecting such invalid headers in 
requests, then feel free to send an error response. That is your choice. 
But I won't fault someone else for doing otherwise.

Note that duplicated headers could also appear in responses. In that 
case you can't send an error response, so you will have to cope some 
other way.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SDP in 200 to UPDATE without SDP

[Paul Kyzivat]

On 12/6/11 7:00 PM, Stefan Sayer wrote:
> Hello,
>
> I am wondering what to do with an SDP in a 200 to an UPDATE without
> SDP in an established dialog, for example as a response to a session
> refresh triggered by SST. There is two cases:
>- the SDP has not changed (to what is established)
>- the SDP has changed
>
> I can't find any text neither in RFC 3311 nor in 3264 which would
> explicitely prohibit placing an SDP in such a 200 reply. In  RFC 6337
> Table 1, though, the only pattern of offer/answer involving UPDATE is
> the one with offer in the UPDATE, and answer in the 2xx.

There was a lot of careful parsing of the various RFCs and inference to 
arrive at that table.

> Or is such an SDP considered a "Session Description That Is Not an
> Offer or an Answer" (2.4 in 6337) and thus should just be considered
> informational? What if the SDP is different to the established session?

Yes, I would consider it a session desc that is not an offer or answer. 
You could ignore it, or you could fail the call. Odds are that things 
will not go well in this case, because the UA that sent this probably 
had *something* in mind about what it is expecting to result. You might 
get lucky if ignoring it is what was expected. Or you might not.

I would argue that the implementation sending this is in error, and 
should be changed.

Thanks,
Paul

> Thanks for any hints!
> Stefan
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Duplication of SIP Header

[Paul Kyzivat]

The examples below look like some sort of conformance test, rather than 
cases that would actually be encountered in practice. If so, I suppose 
either you are implementing the tester and looking for what response to 
expect, or else you have failed a conformance test and are looking for 
an argument about why the tester is wrong.

For the most part 3261 does not mandate behavior for non-conforming 
cases. So in general for the cases you describe almost any behavior 
would be ok. It then becomes a "quality of implementation" issue, not a 
conformance issue.

Also, you have two kinds of cases below:
- repetition of headers that are only permitted to occur once
   (e.g. To, From, Call-ID)
- repetition of headers that can appear more than once, but in a
   form that makes little sense. (E.g. Via)

In the former case, the recipient might notice the duplication and 
object to it. Or it might not notice, and just process one of the 
instances of the header. Either is ok.

In the latter case, you need to look into the details. E.g. for Via, as 
long as the vias get cleaned up while routing the response, and the 
response gets where it should, then all is well.

Thanks,
Paul

On 11/30/11 9:46 PM, Keerthi Srinivasan wrote:
> Hi All,
>
> If the SIP stack receives the duplication Mandatory SIP Header then the SIP
> will send failure response or successful response.
>
> Ex:
> Scenario 1:
>
> Registrar receives the REGISTER request with *duplication of multiple From
> Header like*
> REGISTER sip:registrar.biloxi.com SIP/2.0
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Max-Forwards: 70
> To: Bob
> From: Bob;tag=456248
> From: Bob;tag=456248
> From: Bob;tag=456248
> From: Bob;tag=456248
> From: Bob;tag=456248
> Call-ID: 843817637684230@998sdasdh09
> CSeq: 1826 REGISTER
> Contact:
> Expires: 7200
> Content-Length: 0
>
> Scenario 2:
>
> Registrar receives the REGISTER request with *duplication of multiple To
> Header *
>
> REGISTER sip:registrar.biloxi.com SIP/2.0
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Max-Forwards: 70
> To: Bob
> To: Bob
> To: Bob
> To: Bob
> To: Bob
> To: Bob
> From: Bob;tag=456248
> Call-ID: 843817637684230@998sdasdh09
> CSeq: 1826 REGISTER
> Contact:
> Expires: 7200
> Content-Length: 0
>
> Scenario 3:
>
> Registrar receives the REGISTER request with *duplication of multiple Via
> Header *
>
> REGISTER sip:registrar.biloxi.com SIP/2.0
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Max-Forwards: 70
> To: Bob
> From: Bob;tag=456248
> Call-ID: 843817637684230@998sdasdh09
> CSeq: 1826 REGISTER
> Contact:
> Expires: 7200
> Content-Length: 0
>
> Scenario 4:
>
> Registrar receives the REGISTER request with* duplication of multiple
> Call-ID Header *
>
> REGISTER sip:registrar.biloxi.com SIP/2.0
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Max-Forwards: 70
> To: Bob
> From: Bob;tag=456248
> Call-ID: 843817637684230@998sdasdh09
> Call-ID: 843817637684230@998sdasdh09
> Call-ID: 843817637684230@998sdasdh09
> Call-ID: 843817637684230@998sdasdh09
> Call-ID: 843817637684230@998sdasdh09
> CSeq: 1826 REGISTER
> Contact:
> Expires: 7200
> Content-Length: 0
>
> Scenario 5:
>
> Registrar receives the REGISTER request with *duplication of multiple Cseq
> Header *
>
> REGISTER sip:registrar.biloxi.com SIP/2.0
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Max-Forwards: 70
> To: Bob
> From: Bob;tag=456248
> Call-ID: 843817637684230@998sdasdh09
> CSeq: 1826 REGISTER
> CSeq: 1826 REGISTER
> CSeq: 1826 REGISTER
> CSeq: 1826 REGISTER
> CSeq: 1826 REGISTER
> Contact:
> Expires: 7200
> Content-Length: 0
>
> Scenario 6:
>
> Registrar receives the REGISTER request with *duplication of multiple
> Max-Forwards Header *
>
> REGISTER sip:registrar.biloxi.com SIP/2.0
> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
> Max-Forwards: 70
> Max-Forwards: 70
> Max-Forwards: 70
> Max-Forwards: 70
> Max-Forwards: 70
> To: Bob
> From: Bob;tag=456248
> Ca

Re: [Sip-implementors] Retransmitted NOTIFY overlaps with the next one - what is the correct behavior?

[Paul Kyzivat]

Lets ask Adam to comment on this.

Adam?

Thanks,
Paul

On 11/24/11 7:56 AM, Stefan Sayer wrote:
> o Paul Kyzivat on 11/23/2011 07:17 PM:
>> On 11/23/11 9:21 PM, Robert Szokovacs wrote:
>>> Hi,
>>>
>>> I have the following setup: a B2BUA based on sipstack "A" and a
>>> mediaserver,
>>> based on sipstack "B".
>>> Themediaserver sends a REFER to the B2BUA which starts to send NOTIFYs
>>> according to the progress of the REFERred call: for example: 100,
>>> 183,. 180,
>>> 200. One of the NOTIFY gets lost on the network, lets say the 183,
>>> the "A"
>>> stack retransmits it, but before the retransmittion, the 180 is sent and
>>> replied:
>>>
>>> 100->
>>> <--OK(100)
>>> 183->
>>> 180->
>>> <-OK(180)
>>> 183(r)->
>>> <-500
>>> ("A" stack terminates the subscription)
>>>
>>> The "B" stack refuses the retransmitted 183 NOTIFY with 500, because
>>> it's cseq
>>> is smaller than the 180's, which seems correct as per 12.2.2 of RFC3261:
>>> "
>>> If the remote sequence number was not empty, but the sequence number
>>> of the request is lower than the remote sequence number, the request
>>> is out of order and MUST be rejected with a 500 (Server Internal
>>> Error) response.
>>> "
>>>
>>> The "A" stack in turn terminates the subscription and the transaction
>>> dies,
>>
>> The main problem here is that the "A" stack should not terminate the
>> subscription. This error should only affect the NOTIFY transaction at
>> hand. (See RFC 5057, section 5.1).
> I would have thought so, too (and IMO it's the sensible thing to
> assume), but RFC 3265 3.2.2. says this:
>
> A NOTIFY request is considered failed if the response times out, or a
> non-200 class response code is received which has no "Retry-After"
> header and no implied further action which can be taken to retry the
> request (e.g., "401 Authorization Required".)
>
> ...
>
> If the NOTIFY request fails (as defined above) due to an error
> response, and the subscription was installed using a soft-state
> mechanism, the notifier MUST remove the corresponding subscription.
>
> A notify error response would generally indicate that something
> has gone wrong with the subscriber or with some proxy on the way
> to the subscriber. If the subscriber is in error, it makes the
> most sense to allow the subscriber to rectify the situation (by
> re-subscribing) once the error condition has been handled. If a
> proxy is in error, the periodic SUBSCRIBE refreshes will re-
> install subscription state once the network problem has been
> resolved.
>
>
> so I don't understand how in RFC 5057, section 5.1, 500 (or unknown 5xx)
> show up in "Transaction Only" and not in "Destroys Usage" - what am I
> missing?
>
> thanks!
> Stefan
>
>>
>>> because the mediaserver application expects to receive more NOTIFYs,
>>> at least
>>> one with "subscription-state: terminated", but it never comes. The
>>> "B" stack
>>> doesn't notify the mediaserver application, so has no way of knowing
>>> something
>>> went wrong.
>>>
>>> What would be the correct behavior?
>>> Should the B2BUA hold the sending of the next NOTIFY until it doesn't
>>> receive
>>> reply to the last one?
>>> Should the "A" stack marshall the NOTIFYs and make sure they don't
>>> get out of
>>> order?
>>
>> There is a general issue with overlapping NOTIFYs if one gets lost or
>> delayed, which you are seeing here. The proper way to deal with this
>> depends on the details of the event package. For some event packages it
>> can cause a real mess and the only good solution is to delay sending the
>> next notify till the last one is known to have been received.
>>
>> But in other cases, like this one, it doesn't really matter much if one
>> is lost as long as a subsequent one is received. So in this case its
>> sufficient for "A" to send then as the state changes, so long as it
>> properly handles a 500 response - by just ignoring it when a subsequent
>> notify is known to have been sent.
>>
>>> Should the "B" stack accept out-of-order NOTIFYs?
>>
>> NO!
>>
>> Thanks,
>> Paul
>>
>>> Thank you in advance!
>>>
>>> br
>>>
>>> Szo
>>>
>>>
>>> ___
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Retransmitted NOTIFY overlaps with the next one - what is the correct behavior?

[Paul Kyzivat]

On 11/23/11 9:21 PM, Robert Szokovacs wrote:
> Hi,
>
> I have the following setup: a B2BUA based on sipstack "A" and a mediaserver,
> based on sipstack "B".
> Themediaserver  sends a REFER to the B2BUA which starts to send NOTIFYs
> according to the progress of the REFERred call: for example: 100, 183,. 180,
> 200. One of the NOTIFY gets lost on the network, lets say the 183, the "A"
> stack retransmits it, but before the retransmittion, the 180 is sent and
> replied:
>
> 100->
><--OK(100)
> 183->
> 180->
>   <-OK(180)
> 183(r)->
>   <-500
> ("A" stack terminates the subscription)
>
> The "B" stack refuses the retransmitted 183 NOTIFY with 500, because it's cseq
> is smaller than the 180's, which seems correct as per 12.2.2 of RFC3261:
> "
> If the remote sequence number was not empty, but the sequence number
> of the request is lower than the remote sequence number, the request
> is out of order and MUST be rejected with a 500 (Server Internal
> Error) response.
> "
>
> The "A" stack in turn terminates the subscription and the transaction dies,

The main problem here is that the "A" stack should not terminate the 
subscription. This error should only affect the NOTIFY transaction at 
hand. (See RFC 5057, section 5.1).

> because the mediaserver application expects to receive more NOTIFYs, at least
> one with  "subscription-state: terminated", but it never comes. The "B" stack
> doesn't notify the mediaserver application, so has no way of knowing something
> went wrong.
>
> What would be the correct behavior?
> Should the B2BUA hold the sending of the next NOTIFY until it doesn't receive
> reply to the last one?
> Should the "A" stack marshall the NOTIFYs and make sure they don't get out of
> order?

There is a general issue with overlapping NOTIFYs if one gets lost or 
delayed, which you are seeing here. The proper way to deal with this 
depends on the details of the event package. For some event packages it 
can cause a real mess and the only good solution is to delay sending the 
next notify till the last one is known to have been received.

But in other cases, like this one, it doesn't really matter much if one 
is lost as long as a subsequent one is received. So in this case its 
sufficient for "A" to send then as the state changes, so long as it 
properly handles a 500 response - by just ignoring it when a subsequent 
notify is known to have been sent.

> Should the "B" stack accept out-of-order NOTIFYs?

NO!

Thanks,
Paul

> Thank you in advance!
>
> br
>
> Szo
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Can REFER take place during reINVITE?

[Paul Kyzivat]

On 11/22/11 11:40 AM, Adam Frankel (afrankel) wrote:
> Hi All,
>
> I am seeing a scenario for an established call in which an outbound
> reINVITE is being done, the far end is sending a TRYING and then a REFER
> immediately.  We are rejecting this REFER with a 400 Bad Request because
> the INVITE transaction has not been completed.
>
> I am not clear whether REFER is allowed mid reINVITE or if the far end
> should wait for the 200OK/ACK to complete before sending the REFER.
> I took a look a RFC3515 but it does not appear to state either way
> whether this is allowed.   Can anyone comment?

AFAIK it is not forbidden. IMO your best course of action is to allow it 
and make it work.

Nothing says you have to hurry when acting on the REFER. You can just 
note it, and act on it when it is convenient - e.g. after the re-INVITE 
is complete. But for transaction timing reasons you will need to send 
the 200 for the REFER, and perhaps send an initial NOTIFY for the refer 
event.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] 200 after [3456]XX in a Proxy client transaction: what to do?

[Paul Kyzivat]

On 11/22/11 2:04 AM, Iñaki Baz Castillo wrote:
> Hi, imagine a Proxy which first receives a 480 response and forwards
> it upstream to the UAC (and receives the ACK) but later, for some
> annoying reason, the Proxy receives a 200 for the same client
> transaction.
>
> Should the client discard it? or should it route it? (let's assume
> that it occurs in the same second so the transaction still is in
> memory, but in "completed" state.
>
> I know that in case of two 2XX, the second one would find the client
> transaction in "accepted" state (RFC 6026) so it should let the second
> 2XX to go to the UAC. But in the case I propose the first final
> response was a 480. RFC 6026 section 8.4 (in figure 5: INVITE client
> transaction) does not tell what to do in case of receiving a 2XX while
> in "completed" state.
>
> Thanks a lot.

Somebody is breaking the rules. I can see of no valid way for this to 
occur. The forking proxy should not have let both responses through.

So I think you can do whatever you think will work best for you.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Offer-Answer Query - Related to Slow start INVITE

[Paul Kyzivat]

On 11/22/11 1:27 AM, Kumar, Puneet (Puneet) wrote:
> Hi All,
>
>
>
> I am working on a implementation issue where SIP message flow is:
>
>
>
> UAC   UAS
>
> -INVITE w/o SDP>
>
> <---200 OK w/SDP
>
>
>
> Here UAC sends a slow start INVITE to UAS.
>
> UAS replies with a offer in 200OK.
>
>
>
> Now this 200OK has codec's which UAC doesn't support.

I presume you mean that the offer contains *no* codecs that the UAC can 
support.

You must send an ACK. So send one with an answer that has the port set 
to zero in the m-line with the unacceptable codecs, thus rejecting it.

After that you have two choices:

- send a BYE

- send a re-INVITE with an offer that suits you.

> What should be the response if this INVITE is a reINVITE w/o SDP ?

I think the same strategy works. But you could then re-offer what had 
previously worked, with a higher expectation that it would work again.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] RFC 3261: quoted-string and quoted-pair

[Paul Kyzivat]

On 11/15/11 11:24 PM, Worley, Dale R (Dale) wrote:
>> From: Brett Tate [br...@broadsoft.com]
>>
>> Concerning the quoted-string and quoted-pair BNF, it allows useless
>> escaping of characters within the quoted string.  For instance,
>> "value" can uselessly be escaped as "\v\a\l\u\e".  Are they
>> equivalent?
>
> The general practice seems to be to consider quoted non-special
> characters to be equivalent to the plain characters.  E.g., in section
> 19.1.4:
>
>o  Characters other than those in the "reserved" set (see RFC 2396
>   [5]) are equivalent to their ""%" HEX HEX" encoding.
>
> We've been assuming that the same holds true for quoted-string.

I would agree. This of course means that one must process strings for 
escapes before comparing them.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Multiple Expire parameter in Contact header

[Paul Kyzivat]

Kutay,

Yes, you need to handle this.

Each contact can have its own expiration time setting, which is what you 
see here. The way to treat this is to consider the value in the Expires 
header (if any) as a default value for every Contact, which is then 
overridden by an expires header field parameter (if any) on each Contact 
header field.

An algorithm for doing this might be:

- set default expiration time to an implementation-specific default
   (your choice)
- if there is an Expires header in the REGISTER message,
   set the default expiration time to the value in that header
- process each Contact header field in turn
   - set the expiration time for this header to the default set above
   - if there is an expires header field parameter, set the expiration
 time for this header to that value

Note that the example you show below is a good one to illustrate why you 
might want this. It is adding one contact uri and simultaneously 
removing another.

Thanks,
Paul

On 11/10/11 10:14 AM, Kutay OZDOGRU wrote:
> Hi all,
>
> I have a sipserver that registers multiple clients to IMS side however,
> when my sipserver gets 200 OK message for
> De-register as below, it faces confusion because of 2 expire parameters.
>
> m:
> ;description="Login";expires=84703;
> +sip.instance="";reg-id=1
> ,;expires=0
>
>
> There is no expire header in 200 OK message so expire parameter is in
> contact header but why remote sip server sends me
> 2 different expires
>
> How can I be sure about which expire should I use? :S
>
> I have a confusion on this point. I cannot find any information about
> this in RFC3261... is it applicable?
> Do I have to  handle this?
>
> Could you please give me your comments?
>
> Thanks,
> Kutay
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] RFC 3261: User-Agent and Server within response

[Paul Kyzivat]

On 11/9/11 9:47 AM, Worley, Dale R (Dale) wrote:
>> From: Sairam POKKUNURI [sair...@ipinfusion.com]
>>
>> we dont care what type of phones or their properties are if they can send
>> and recieve properly
>
> OTOH, when you discover that some element is *not* sending properly, it is
> very useful if you can examine the message and determine the particular 
> element
> that sent the message, and the particular version of software it is running.
>
> That is why we recommend that all elements include User-Agent/Server in all
> SIP messages.

Unfortunately, I have heard this advanced as a reason *not* to include 
it, and for elements such as SBCs to remove it. Including this 
information discloses the equipment you are using, which is sometimes 
viewed as a business secret, and the info can also be used to select 
exploits of version-specific bugs.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] RFC 3261: User-Agent and Server within response

[Paul Kyzivat]

Brett,

I suspect that this bias of Server to UAS and User-Agent to UAC is an 
inadvertent carryover when the definitions of these header fields were 
borrowed from HTTP. Since HTTP is an asymmetric client/server protocol, 
the server always sends responses, and the client always sends requests.

But in SIP, if a UA is responding to a request, IMO it makes much more 
sense for it to include a User-Agent header than a Server header. Its 
more interesting to speculate when a Server header should be put into a 
request. (By definition only a UA can originate a request, except for 
CANCEL and ACK.) Its also interesting to consider when a UA would insert 
a Server header into a response.

It would be wise for implementers to be very generous in what they 
accept here.

Thanks,
Paul

On 11/8/11 1:43 PM, Brett Tate wrote:
> [sorry for the resend... fixed section reference]
>
> Howdy,
>
> RFC 3261 sections 20.35 and 20.41 appear to indicate that Server is for 
> responses and User-Agent is for requests.  However, table 3 indicates that 
> User-Agent is also for responses.
>
> Is User-Agent really expected within responses?  If so, would it be strange 
> if User-Agent and Server are present and not equivalent within a response?
>
> For what it is worth... as part of the debate about fixing/deprecating table 
> 2, Adam's original effort to fix table 2 does still show User-Agent within 
> responses.
>
> http://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html
>
> Thanks,
> Brett
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Reg: Replace Header in REFER Message

[Paul Kyzivat]

On 11/3/11 3:10 PM, prakash k wrote:
> Hi All,
>
> In "Replaces:"  whether the order is mandatory, ( what is meant is) followe
> by callid  information ,to-tag should come first then only from-tag
>
>
> as per RFC 3891
>
> ABNF
>
>Replaces= "Replaces" HCOLON callid *(SEMI replaces-param)
>replaces-param  = to-tag / from-tag / early-flag / generic-param
>to-tag  = "to-tag" EQUAL token
>from-tag= "from-tag" EQUAL token
>early-flag  = "early-only"

There is no ordering requirement. The server is clearly broken below.

Thanks,
Paul

> Scenario1:
>
> Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321
>
>
> Server responds properly in this case
>
> Scenario2:
>
> Replaces: 12adf2f34456gs5;from-tag=54321;to-tag=12345
>
>
> whereas if change the order , as mentioned above in scenario2 , server
> sends 481
>
>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] RFC 6337 and 3GPP TS 24.610: resuming from hold

[Paul Kyzivat]

On 11/3/11 1:10 PM, Brett Tate wrote:
> Howdy,
>
> RFC 6337 and 3GPP TS 24.610 
> (http://www.3gpp.org/ftp/Specs/html-info/24610.htm) appear to be in conflict 
> concerning resuming from hold.  However, it may just be a poor interpretation 
> of 3GPP TS 24.610 when a sendonly offer (from X) is answered with inactive 
> (by Y).
>
> 3GPP TS 24.610 section 4.5.2.1 appears to indicate that X should offer 
> recvonly instead of sendrecv when resuming.  RFC 6337 section 5.3 explicitly 
> indicates that X would offer sendrecv.
>
> Anyone know if discrepancy is intentional?

I don't know why 24.610 was written that way.
It will probably not cause problems most of the time - e.g. if its 
interoperating with another UA following the same rules.
But there are other reasons for ending up at inactive, and this might 
not work with those.

Fundamentally its silly to offer recvonly if you really want to send.

Thanks,
Paul


> Thanks,
> Brett
>
> -
>
> RFC 6337:
>
> "Once in this state, to resume a two-way exchange of media, each side
> must reset its local hold status.  If UA1 is first to go off hold, it
> will then send an offer with "a=sendrecv" attribute.  The UA2 will
> respond with its desired state of "a=sendonly" attribute because that
> is a permitted response.  When UA2 desires to also resume, it will
> send an offer with "a=sendrecv" attribute.  In this case, because UA1
> has the same desire it will respond with "a=sendrecv" attribute.  In
> the same case, when UA2 receives the offer with "a=sendrecv"
> attribute, if it has decided it wants to reset its local hold but has
> not yet signaled the intent, it may send "a=sendrecv" attribute in
> the answer."
>
> --
>
> 3GPP TS 24.610:
>
> "If all the media streams that shall be resumed, the invoking UE shall 
> generate a session level direction attribute, or separate media level 
> direction attributes, in the SDP that is set to:
>
> - "recvonly" if the streams were previously inactive media streams; or
>
> - "sendrecv" if the streams were previously sendonly media streams, or the 
> attribute may be omitted, since sendrecv is the default."
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Binary bodies in SIP?

[Paul Kyzivat]

On 11/1/11 11:23 AM, Hadriel Kaplan wrote:

> And someone sends binary encoded payloads for DTMF indications in SIP NOTIFY 
> requests - I don't remember who it is, but I remember it because it's so 
> crazy (the MIME body's content is literally an RFC 2833 RTP DTMF event 
> packet, minus the IP and UDP header).

That is crazy!

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Binary bodies in SIP?

[Paul Kyzivat]

I think I recall some work from long ago that banned use of 
Content-Transfer-Encoding. (But I'm not sure I remember it right.) It 
might have been Cullen who did it.

Does that ring any bells?

Thanks,
Paul

On 11/1/11 11:00 AM, Worley, Dale R (Dale) wrote:
>> From: Olle E. Johansson [o...@edvina.net]
>>
>> Now, images can of course be encoded or sent binary. The RFC doesn't
>> give us recommendations, so I guess you will have to track back to the
>> original set of documents for MIME.
>
> The text of 3261 doesn't mention it, but the examples show
> "Content-Transfer-Encoding: base64" for some body parts.
>
>> (Surprised that Dave did not find that :-) )
>
> It's "Dale", please!
>
> Dale
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Register to a domain without username in the AOR

[Paul Kyzivat]

+1

On 10/31/11 10:46 AM, Worley, Dale R (Dale) wrote:
>> From: Olle E. Johansson [o...@edvina.net]
>>
>> RFC 3261 is not totally clear in the topic of AORs you can register
>> to. It seems to indicate any URI, but mentions usernames in most
>> examples.
>
> In practice, what you can register to is what the registrar for the
> domain in question will accept.  So it is a matter between the UA and
> the registrar; no other element has any reason to care.
>
> Dale
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Query of receiving re-INVITE without offer

[Paul Kyzivat]

See section 5 of RFC 6337. It covers exactly this point.
If you don't do something like what is described there you run a risk of 
getting into a situation where you can't get out of hold state.

Thanks,
Paul

On 10/14/11 1:28 AM, deepak bansal wrote:
> Hi Tarun,
>
> Please help on below scenario:
> --
>
> B now has one RTP stream (Port1) marked as INACTIVE, due to HOLD initiated
> by A
>
> a) Should it send 1 "m" line in SDP, send offer on RTP stream Port1 (making
> it as SENDRECV) with full Caps.
>  (In this case I am worried about the session that was put ON-HOLD by A)
>
>  OR
>
> b) Should it send 2 "m" lines in SDP
>  One with Port1 INACTIVE (i.e previous SDP that was send)
>  2nd  with Port2 sendrecv with Full Capabilities
>  (In this case I am worried whether i Can create two RTP Audio streams
> one INACTIVE and other SENDRECV)
>
> EXAMPLE
> 
>
> A  (Controller)  B
>
> C
>
> 1) A and B are on Call
> 2) A initiated HOLD by pressing flash HOOK (so B is now on HOLD)
> 3) A establish Call with C
> 4) A goes On Hook
> 5) Controller does not Pass this to B instead it sends INVITE without offer
> to B
>
> SO B was on HOLD with previous SDP that it has send towards controller
> (inactive)
> Now it has received SDP without Offer, so how should B behave.
>
>
> Best Regards
> Deepak
>
>
> On Fri, Oct 14, 2011 at 10:28 AM, Tarun2 Guptawrote:
>
>> Hi Deepak
>>
>> The scenario is perfectly valid. Refer RFC 3725 for more such examples. A
>> is using ReInvite without SDP to elicit a new offer from B. Yes, B can send
>> new offer with full capabilities in 200 OK.
>>
>> Regards,
>> Tarun Gupta
>> Aricent
>>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of deepak bansal
>> Sent: Friday, October 14, 2011 10:09 AM
>> To: sip-implementors
>> Subject: [Sip-implementors] Query of receiving re-INVITE without offer
>>
>> User A and User B are on HOLD (User A has initiated HOLD by sending
>> (inactive))
>> User B now receives a re-INVITE without offer from User A, then should B
>> respond with offer in 200 OK ??
>>
>> Is this a VALID Scenario,
>> If it is yes what should be send by B in SDP Body of 200OK.
>> a) Previously SDP response that it has sent in 200 OK (inactive))
>> 2) Can B send offer with (sendrecv mode) with full capabilities?
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>>
>>
>>
>> ===
>> Please refer to http://www.aricent.com/legal/email_disclaimer.html
>> for important disclosures regarding this electronic communication.
>>
>> ===
>>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] How to detect UA calling itself

[Paul Kyzivat]

On 9/26/11 12:00 PM, Worley, Dale R (Dale) wrote:
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Ramesh Babu 
> Kuppili [rkupp...@zhone.com]
>
> We have a analog to SIP gateway that collects digits dialed from POTS lines 
> and initiates the SIP call by sending INVITE to a proxy server.
>
> How can a user agent detect that it is calling itself in SIP? Either from 
> incoming INVITE or from a INVITE response?
>
> We have to implement a feature which gets triggered based on this situation.
> ___
>
> If an incoming INVITE has a Call-Id that is the same as the Call-Id of an 
> INVITE that the UA sent...

This works in simple cases.

But if the call traverses an SBC or gateway before getting back to 
itself, it can get difficult to tell.

Depending on what you are trying to do, you can either ignore this case, 
treating it as not a call to self, or else you can employ heuristics to 
decide when you know you have an outgoing call pending.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] 300 Multiple choices

[Paul Kyzivat]

On 9/25/11 1:56 PM, Cesar Fiestas wrote:
> Hello
>
> Can anyone post a valid call flow or session that involves a 300 Multiple
> choices message? Thanks
>

Consider a typical case of a proxy/registrar handling an AOR, with 
multiple UAs registered to that AOR.

Then the proxy receives a call addressed to the AOR. It can:
- serial fork the call to the registered contacts
- parallel fork the call to the registered contacts
- pick one of the registered contacts and return a 301/302
   with it
- return a 300 with all the registered contacts and let the
   UAC do the forking
- ...

If it decides to return a 300 with multiple contacts, it can use 
q-values to reflect the relative priority of the contacts, just as they 
were specified at registration.

UACs MUST be prepared to deal with this. Really stupid ones will fail 
the call. Stupid ones will retry once with the first contact in the 3xx. 
Reasonable ones will do serial and parallel forking based on q-values 
and/or local policy.

And don't forget that when retrying with the returned contacts, you can 
get additional 3xx responses.

3261 describes what you should do.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] AOR matching

[Paul Kyzivat]

At end

On 9/23/11 11:35 AM, Worley, Dale R (Dale) wrote:
>> From: isshed [isshed@gmail.com]
>>
>> I have registered my UAC with AOR and Contact as follows.
>>
>> AOR: sip:1...@example.com
>> Contact: sip:1234@a.b.c.d
>>
>> Then I got an INVITE with req uri and To header as follows.
>>
>> Req URI: sip:1234@a.b.c.d
>> To: sip:1234@w.x.y.z
>>
>> where
>> w.x.y.z = resolved IP of example.com
>> a.b.c.d = UAC's IP.
>>
>> My UAC returns 403 forbidden since it does not match the AOR. Is it a valid
>> behavior? can you please provide the reference for the same?
>
> I cannot imagine that this is correct behavior -- The INVITE arrives
> with the registered contact URI as its request URI, and the phone
> rejects it!
>
> (BTW, you have forgotten to specify the "it" that does not match the
> AOR.)
>
> In regard to the To header, the phone should *not* be examining it.
> The To header is the caller's initial request, and there is no reason
> to expect that to be the same as the destination phone's AOR.  What if
> the call reaches this phone due to call forwarding?

In general I agree with Dale on this.

However it is within the rights of the UAS to examine the To header and 
vary its behavior, if it has some good reason to do so. For instance, if 
the To-URI isn't one it considers itself to be responsible for, it might 
inform its user that this is a special (probably forwarded) call.

Conceivably one might want to configure their phone not to accept 
forwarded calls. If so, the behavior described here might make sense. 
But IMO this ought the be the exception, not the default behavior for 
any device.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Proxy-Require values

[Paul Kyzivat]

On 9/19/11 11:24 AM, Iñaki Baz Castillo wrote:
> 2011/9/19 Worley, Dale R (Dale):
>> Well, the behavior if they are used in Proxy-Require is specified,
>> but you should check the RFC to see whether it is supposed to be
>> used.  E.g., the text in sip-parameters talks about using "Proxy-Require:
>> 199", but RFC 6228 forbids using that in any situation:
>>
>> section 4:
>>
>>A UAC SHOULD NOT insert a "199" option-tag in the Require
>>or the Proxy-Require header field [RFC3261] of the request, since in
>>many cases it would result in unnecessary session establishment
>>failures.
>>
>> section 5:
>>
>>The
>>UAS MUST NOT insert a "199" option-tag in the Supported, Require, or
>>Proxy-Require header field of the 199 response.
>>
>> section 6:
>>
>>The proxy MUST NOT insert a "199"
>>option-tag in the Supported, Require, or Proxy-Require header field
>>of the 199 response.
>
> Good points :)
>
> Hoewer text above says that the UAC/UAS should not use such
> Proxy-Require values, but in case they are present, the proxy must
> reject the request if it does not support the option-tag.

Yes. But I think you have asked the wrong question.
The question you should be asking is:

which option tag values should a Proxy support, or at least consider 
supporting?

The vast majority of options don't require any special behavior on the 
part of a proxy. A "nice" proxy would probably allow a request with 
Proxy-Require for those options to succeed.

Then there is the list of options where a supporting proxy must actually 
*do* something. For each of those, the proxy will either include support 
or not, and handle Proxy-Require accordingly.

And then or course the proxy should fail any request with a 
proxy-require for some other option.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Inter Vendor Offer/Answer a=inactive

[Paul Kyzivat]

I support what Dale says. For more info, see section 5.3 of RFC 6337.

Thanks,
Paul

On 9/15/11 4:59 PM, Worley, Dale R (Dale) wrote:
>> From: Sproul, Barry K [barry.spr...@verizonwireless.com]
>>
>> I have an issue between 2 vendor platforms that causes permanent audio
>> on hold. Initial invite from party A contains SDP offer with sendrcv
>> and multiple codecs. Party B returns 200ok with SDP answer and
>> includes attribute of a=inactive with multiple codecs. Party A
>> reinvites with 2 preferred codecs to lock down media also adds the
>> a=inactive attribute. At this point the call is without audio both
>> directions indefinitely. I cannot find this scenario explained in RFC
>> 3264. I can find example of a=inactive in the offer but not answer.
>
> Each side is responsible for managing the "on hold" state that it
> creates.  Its current on-hold state is shown by whether it indicates
> that it is willing to receive media.  When a UA provides an offer, it
> should offer all media directions that it is willing to support at
> that moment, viz., sendrecv if it is not on-hold, sendonly if it is on
> hold and willing to provide on-hold media, and inactive if it is on
> hold and not willing to provide on-hold media.  When a UA provides an
> answer, it should offer all media directions that are in the offer and
> that it is willing to support.
>
> In this case, A initially indicates that it is not placing the call on
> hold by offering sendrecv.  B answers that it has the call on-hold and
> is not providing on-hold media.
>
> When A re-INVITEs, it should offer sendrecv again, as that is what it
> is willing to do at that moment.  When A sends inactive, it is
> indicating that it has placed the call on-hold and is not providing
> on-hold media, despite that A's user has not executed the hold
> function.
>
> Note particularly that when a UA provides an offer, it does *not* copy
> the directionality from the SDP last provided by the other UA, it
> offers everything that it is willing to support at that time.
>
> Dale
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Question about basic transfer (unattended) in RFC 5589

[Paul Kyzivat]

On 9/12/11 12:03 PM, Francis Joanis wrote:
> Hi,
>
> Apologies if this has been answered before...
>
> I have a question about when the BYE between the Transferor and the
> Transferee is sent in the case of an unattended transfer.
>
> RFC 5589 says in Section 6 that "[the transferor] could emit a BYE to
> the Transferee as soon as the REFER transaction completes". In Figure
> 1, it is shown that the BYE is sent after the processing of the NOTIFY
> (SipFrag 200 OK).
>
> I assume that this is the current best practice but I have also
> noticed that the unattended transfer diagram shown on tech-invite.com
> (http://www.tech-invite.com/Ti-sip-service-04.html) shows the BYE
> being sent after the processing of the NOTIFY (SipFrag 100 Trying), so
> before the end of the REFER transaction.
>
> When implementing a UA that needs to act as the Transferee (i.e.
> receive the REFER), would it be safe to assume that the BYE can only
> be received once the new INVITE transaction (to the transfer target)
> has been completed (i.e. after the 200/ACK), or should the UA also
> support receiving the BYE before receiving the final response for the
> INVITE (like shown in
> http://www.tech-invite.com/Ti-sip-service-04.html)?

You can do this in a variety of ways, as you wish:

- when you get the 200 to the REFER
- when you get *some* NOTIFY as a result of the REFER
- when you get a NOTIFY that indicates the success of the resulting INVITE
- when you get the NOTIFY indicating termination of the subscription

The main concern is that you not send the BYE too soon, and so about the 
call without there being a replacement. For that, *either* a 200 to the 
REFER or a NOTIFY, whichever comes first, is probably sufficient.

Beyond that, it depends if you have any logic to recover if the REFER 
fails. If not, then the above is probably fine. If you can recover in 
some way, then you might want to wait till you can verify that the REFER 
resulted in a successful INVITE, and otherwise keep the call and do the 
recovery. (Just displaying that the tranfer failed might be useful.)

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Cannot register with server

[Paul Kyzivat]

On 9/9/11 11:11 AM, Wyne Wolf wrote:
> Never mind guys. The server is locking the account to the IP address the
> account was first used. I guess it was for security reasons. Thanks again.

Great! This server really doesn't get how SIP is supposed to work, and 
what the point of registration is. If its locking to an IP address, 
there is no point in doing registration at all.

Grumble!
Paul

> On Fri, Sep 9, 2011 at 10:38 AM, Wyne Wolf  wrote:
>
>> Yes. The user name and password are both correct.
>>
>> On Fri, Sep 9, 2011 at 10:26 AM, Pavesi, Valdemar (NSN - US/Irving)<
>> valdemar.pav...@nsn.com>  wrote:
>>
>>> Is the username/password correct ? if header Authorization is not
>>> correct the server will keep sending  the challenge   up to a limit
>>> (like 50 times)
>>>
>>> To avoid   loop.  After reach the maximum you must see  403 instead 401.
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Original Message-
>>> From: sip-implementors-boun...@lists.cs.columbia.edu
>>> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext
>>> Wyne Wolf
>>> Sent: Thursday, September 08, 2011 9:18 PM
>>> To: sip-implementors@lists.cs.columbia.edu
>>> Subject: [Sip-implementors] Cannot register with server
>>>
>>> Hi,
>>>
>>> Can someone look at this log? I can't see what is wrong with it, but the
>>> server refusing registration.
>>>
>>> Thank you.
>>>
>>> Thu Sep 08 21:32:02 Europe/Dublin 2011  Send to //217.10.79.23:5060(522)
>>> REGISTER sip:sipgate.co.uk SIP/2.0
>>> Via: SIP/2.0/UDP
>>> 192.168.0.1:5060;rport;branch=z9hG4bK-8ac3fcfe85ec54e0a767664e61927756-1
>>> 1
>>> Contact:
>>> To:
>>> From: "Me-Test">>> ;tag=8ac3fcfe85ec54e0a767664e61927756
>>> Call-ID: 8ac3fcfe85ec54e0a767664e61927756
>>> User-Agent: BlackVoib 1.5.0
>>> Max-Forwards: 70
>>> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO
>>> CSeq: 11 REGISTER
>>> Expires: 1800
>>> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO
>>> Content-Length:  0
>>>
>>>
>>> Thu Sep 08 21:32:02 Europe/Dublin 2011  Received from
>>> //217.10.79.23:5060;5060|UDP(496)
>>> SIP/2.0 401 Unauthorized
>>> Via: SIP/2.0/UDP
>>> 192.168.0.1:5060
>>> ;received=89.242.35.178;rport=5060;branch=z9hG4bK-8ac3fcfe85ec54e0a76766
>>> 4e61927756-11
>>> To:
>>> ;tag=12353b526ced3f57e916dd04ee4917bc.1799
>>> From: "Me-Test">>> ;tag=8ac3fcfe85ec54e0a767664e61927756
>>> Call-ID: 8ac3fcfe85ec54e0a767664e61927756
>>> CSeq: 11 REGISTER
>>> WWW-Authenticate: Digest realm="sipgate.co.uk",
>>> nonce="4e6926617a9d3add5cf14fba92fc1fc0bc135cb37b4e"
>>> Content-Length: 0
>>>
>>>
>>> Thu Sep 08 21:32:02 Europe/Dublin 2011  Send to //217.10.79.23:5060(727)
>>> REGISTER sip:sipgate.co.uk SIP/2.0
>>> Via: SIP/2.0/UDP
>>> 192.168.0.1:5060;rport;branch=z9hG4bK-8ac3fcfe85ec54e0a767664e61927756-1
>>> 2
>>> Contact:
>>> To:
>>> From: "Me-Test">>> ;tag=8ac3fcfe85ec54e0a767664e61927756
>>> Call-ID: 8ac3fcfe85ec54e0a767664e61927756
>>> User-Agent: BlackVoib 1.5.0
>>> Max-Forwards: 70
>>> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO
>>> Authorization: Digest
>>> username="1363420e0",realm="sipgate.co.uk
>>> ",nonce="4e6926617a9d3add5cf14fba92fc1fc0bc135cb37b4e",uri="sip:
>>> sipgate.co.uk",response="d5dedc4683d6edfcb391c5520203c08f",algorithm=MD5
>>> CSeq: 12 REGISTER
>>> Expires: 1800
>>> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO
>>> Content-Length:  0
>>>
>>>
>>> Thu Sep 08 21:32:02 Europe/Dublin 2011  Received from
>>> //217.10.79.23:5060;5060|UDP(496)
>>> SIP/2.0 401 Unauthorized
>>> Via: SIP/2.0/UDP
>>> 192.168.0.1:5060
>>> ;received=89.242.35.178;rport=5060;branch=z9hG4bK-8ac3fcfe85ec54e0a76766
>>> 4e61927756-12
>>> To:
>>> ;tag=12353b526ced3f57e916dd04ee4917bc.aeba
>>> From: "Me-Test">>> ;tag=8ac3fcfe85ec54e0a767664e61927756
>>> Call-ID: 8ac3fcfe85ec54e0a767664e61927756
>>> CSeq: 12 REGISTER
>>> WWW-Authenticate: Digest realm="sipgate.co.uk",
>>> nonce="4e69266100017acae0c17cbe89251f7294fddc95da8fda22"
>>> Content-Length: 0
>>>
>>>
>>> Thu Sep 08 21:32:02 Europe/Dublin 2011  Send to //217.10.79.23:5060(727)
>>> REGISTER sip:sipgate.co.uk SIP/2.0
>>> Via: SIP/2.0/UDP
>>> 192.168.0.1:5060;rport;branch=z9hG4bK-8ac3fcfe85ec54e0a767664e61927756-1
>>> 3
>>> Contact:
>>> To:
>>> From: "Me-Test">>> ;tag=8ac3fcfe85ec54e0a767664e61927756
>>> Call-ID: 8ac3fcfe85ec54e0a767664e61927756
>>> User-Agent: BlackVoib 1.5.0
>>> Max-Forwards: 70
>>> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO
>>> Authorization: Digest
>>> username="1363420e0",realm="sipgate.co.uk
>>> ",nonce="4e69266100017acae0c17cbe89251f7294fddc95da8fda22",uri="sip:
>>> sipgate.co.uk",response="ad226521a64a4c4c0f0d39d55d7428f0",algorithm=MD5
>>> CSeq: 13 REGISTER
>>> Expires: 1800
>>> Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO
>>> Content-Length:  0
>>>
>>>
>>> Thu Sep 08 21:32:02 Europe/Dublin 2011  Received from
>>> //217.10.79.23:5060;5060|UDP(496)
>>> SIP/2.0 401 Unauthorized
>>> Via: SIP/2.0/UDP
>>> 192.168.0.1:5060
>>> ;received=89.242.35.178;rport=5060;branch=z9hG4bK-8ac3fcfe85ec54e0a76766
>>> 4e61927756-13
>>> To:
>>> ;tag=12353b526ced3f57e916dd0

Re: [Sip-implementors] Record Route header processing for unreliable 18x response at UAC end

[Paul Kyzivat]

On 9/9/11 2:56 AM, Abhishek Sahu wrote:
> Hello All
>
> I've one query regarding behavior of Record-Route. If Record-Route is present 
> in SIP unreliable 18x response and UPDATE needs to be sent prior to receiving 
> of 2xx response. So should the Route header for the UPDATE request be updated 
> according to the Record-Route of 18x response?  In this case the dialog has 
> not been established yet.

Its impossible to send an UPDATE until an [early-]dialog has been 
established.

Yes, the Record-Route needs to be used to construct the Route for the 
UPDATE message.

Thanks,
Paul

> INVITE with Route>
> 180 with Record Route<---
> UPDATE>
>
> Regards
> Abhishek Sahu
> Aricent
>
>
>
>
> ===
> Please refer to http://www.aricent.com/legal/email_disclaimer.html
> for important disclosures regarding this electronic communication.
> ===
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding Display Name when Privacy:id

[Paul Kyzivat]

On 9/9/11 1:27 AM, prakash k wrote:
> Hi All,
>
>
> I have the following scenario:
>
> Incoming invite has Privacy:id  along "From" header carrying "Display Name"
>
> Where as the outgoing INVITE has  "From" Header set
> "sip:Anonymous@Anonymous.invalid" whereas the display-name goes as it is.
>
> Is there any draft mentioning about this behavior handling.

The behavior you show seems to have little/nothing to do with the 
defined behavior for the Privacy header.

The behavior for Privacy:id as described in RFC 3325 only affects the 
P-Asserted-Identity header, not the From header.

Fiddling with the From header would be appropriate if Privacy:user had 
been specified. (See RFC 3323.) But in that case the job was done 
incompletely because the display name was not stripped.

Good Luck,
Paul

> Incoming INVITE has the following
>
> INVITE sip:08012345614@x.x.x.x:5060 SIP/2.0
>
> Via: SIP/2.0/UDPx.x.x.x :5060;branch=z9hG4bKbd51d88-c16058d2
>
> From: "+13109976224";tag=184886456
>
> To:
>
> Privacy: id
>
>
> Outgoing INVITE has the following
>
> INVITE sip:8012345614@x.x.x.x:5060 SIP/2.0
>
> Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK09B013f59d419cd8475
>
> From: *"+13109976224" *;tag=gK09005224
>
> To:
>
>
>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Call Transfer using 3pcc

[Paul Kyzivat]

On 9/6/11 5:02 PM, sathish kumar chevuru wrote:
> Hi,
>
>  In case of Call Transfer using 3pcc and REFER , If the Callee sends out
> REFER without sending INVITE HOLD, What should be the behaviour of 3pcc.
>
>  Does 3pcc sends out INVITE HOLD's to Caller and Callee , before
> initiating the call to Transfer Target ? Are the INVITE HOLD's to Caller and
> Callee MUST in this case ?
>
>  If 3pcc doesn't send INVITE HOLD's to Caller and Callee, What happens to
> the existing RTP path between Caller and Callee ?
>
> Where do i find this information.

To be specific, we really need more info about what you are trying to do 
and what assumptions you are making about the capabilities of the 
various devices.

Based on what you have said, I guess you have the following situation:

A - B  C
|
D . |

where you have an existing call between the A (caller) and C (callee) 
through a B2BUA (B). Apparently C understands REFER and is using it to 
request a transfer from A to D.

If so, then it is up to B to carry out the REFER correctly as seen by C. 
On the other side it can do a variety of things. One of those is a "3pcc 
transfer", by sending an INVITE to D, and then splicing it into the 
referred call with C.

As Dale said, this is not standardized behavior. Its left for the reader 
to figure out. If you have a call flow in mind, post it and people will 
comment on it for you.

Good Luck,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] PRACK Message

[Paul Kyzivat]

On 9/5/11 12:23 AM, Tarun2 Gupta wrote:
> Hi Salil
>
> As per offer answer model, SDP in PRACK can be an offer as well as an answer. 
> Refer RFC 3262
 > and http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-18 
for further details:

The latter is now RFC 6337 (finally!)

Thanks,
Paul

>
> Excerpt from the offer-answer draft:
>
> Offer   Answer RFCIni Est 
> Early
>   ---
>   1. INVITE Req.  2xx INVITE Resp. RFC 3261  Y   YN
>   2. 2xx INVITE Resp. ACK Req. RFC 3261  Y   YN
>   3. INVITE Req.  1xx-rel INVITE Resp. RFC 3262  Y   YN
>   4. 1xx-rel INVITE Resp. PRACK Req.   RFC 3262  Y   YN
>   5. PRACK Req.   200 PRACK Resp.  RFC 3262  N   YY
>
> Regards,
> Tarun Gupta
> Aricent
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Verma, 
> Salil (NSN - IN/Gurgaon)
> Sent: Monday, September 05, 2011 9:46 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] PRACK Message
>
> HI Experts ,
>
>
>
> Do PRACK Msg contain SDP information .   as per Standard theory PRACK is
> only acknowledgement.
>
>
>
> But in my case I can see that Prack is coming with SDP .
>
>
>
> Kindly suggest what can be the reason.
>
>
>
>
>
> Thanks,
> Best Regards
> sAlil veRmA
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
>
> ===
> Please refer to http://www.aricent.com/legal/email_disclaimer.html
> for important disclosures regarding this electronic communication.
> ===
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Response code sent by proxy to caller when UAS not registered

[Paul Kyzivat]

On 8/11/11 3:00 PM, Iñaki Baz Castillo wrote:
> 2011/8/11 Paul Kyzivat:
>> That contrasts with a case where the example.com server receives a
>> request for sip:al...@example.com and discovers that "al...@example.com"
>> is not in the location server, so that registrations for it could not
>> succeed. In that case 404 not found is appropriate.
>
> When you say "discovers that "al...@example.com" is not in the
> location server", do you mean that such user does NOT exist in the
> system (regardless it's SIP registered or not)? I assume you mean
> that.

Yes, that is what I meant.

> If not, I don't agree as 480 would be the correct response :)
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Response code sent by proxy to caller when UAS not registered

[Paul Kyzivat]

On 8/11/11 12:53 PM, Iñaki Baz Castillo wrote:
> 2011/8/11 Kevin P. Fleming:
>> You are talking about two different things; it's completely possible for
>> a callee's end system to be registered, but for that person to be 'not
>> logged in' (and thus unavailable to receive calls). Having a contact URI
>> registered at the callee's AoR does not mean they are 'logged in', it
>> just means we know how to contact the callee's system to *find out* if
>> they are logged in or not.
>
> Hi, from the RFC 3261 perspective and SIP protocol in general, I don't
> know what "being logged in" means. SIP just talks about devices being
> registered (so can receive calls) or not (just talking about common
> scenarios with dynamic phones).
>
> I don't think that 21.4.18 talks about "a PBX with a queue in which an
> agent is, or is not, logged in". Neither I think it means that the
> human user enables/dissables "something" in the phone device to be
> reachable or not (as that concept is DND and is already present in
> same RFC section).
>
> Anyhow, I agree that the section 21.4.18 is unclear. When it says "The
> callee's end system was contacted successfully but the callee is
> currently unavailable" I expect that "callee's end system" could mean
> its inbound proxy, and not just the callee's own device (the phone).

I largely agree with what Iñaki has said.
I'm not so troubled that this section is unclear - not so much that it 
needs to be fixed. (It would be better if it said nothing about "logged 
in" since that isn't a meaningful concept in sip.)

If you are concerned about devices that are/aren't registered, then you 
must be sending a request to an AOR serviced by a proxy associated with 
the registrar for the AOR. That proxy *is* an end system for that AOR. 
The AOR is *temporarily* unavailable because nothing is registered, and 
presumably *could* be registered.

That contrasts with a case where the example.com server receives a 
request for sip:al...@example.com and discovers that "al...@example.com" 
is not in the location server, so that registrations for it could not 
succeed. In that case 404 not found is appropriate.

Thanks,
Paul

> Indeed RFC 3261 should clarify MUCH MORE the correct response for the
> case in which an AoR is not registered is its proxy/server/registrar.
> But anyhow I really expect that 480 is the appropriate response.
>
> Regards.
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SIP-URI header ABNF

[Paul Kyzivat]

On 8/4/11 5:02 AM, Iñaki Baz Castillo wrote:

> Good point. I confirm that "=" after hvalue is mandatory and as per
> RFC 3261 BNF, the following SIP URI is valid:
>
>sip:qwe.com?qwe=qwe&asd=
>
> while this one is not valid:
>
>sip:qwe.com?qwe=qwe&asd
>
> I've confirmed it using my SIP parser which is 100% strict according
> to RFC 3261 BNF grammar.
>
> Indeed strange and a bit ugly but who is using URI headers? :)

Go read about History-Info (draft-ietf-sipcore-rfc4244bis).

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] BYE before call answer

[Paul Kyzivat]

+1 to what Bob says.

In addition, I suggest you read:

* RFC 5057 Multiple Dialog Usages in the Session Initiation Protocol
* RFC 5407 Example Call Flows of Race Conditions in the
Session Initiation Protocol

Thanks,
Paul

On 8/3/11 3:37 PM, Bob Penfield wrote:
> 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 a BYE does not mean that the UA that 
> received the BYE can simply ignore any pending transaction that may be 
> related to that dialog. That UA must still send a final response to requests 
> that it has received. In the case of receiving a BYE, the recommendation in 
> 3261 is to send a 487 response to each of those pending transactions. The 
> same applies to the UA sending the BYE in that it must still be ready to 
> receive responses on outstanding transactions (i.e. the transaction state 
> machines must continue to run until a final response is received of it times 
> out).
>
>
> cheers,
> (-:bob
>
>
>
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Leo Leo
> Sent: Wednesday, August 03, 2011 2:57 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] BYE before call answer
>
> Hi, Paul,
>
>   There is something missing here, please explain it to me.
>
>> They BYE does *not* "terminate all transactions"!
>> Every transaction must follow its own state machine, independent of any
>> other transaction.
>
>> You MUST attempt to send some final response to any outstanding
>> transactions even if a BYE transaction has been completed.
>
>> The BYE only ends the Invite-dialog-usage.
>
> If BYE only ends the dialog, what does the UA must to do with any other 
> transaction within that dialog? As far as I know, the transactions within a 
> dialog ara attached its existence.
>
> There is no sense to send or to receive some message from earlier 
> transactions (just like retransmissions) after a BYE request or a BYE 
> response received.
>
> Lets say the BYE received has come just after sending the re-INVITE. 
> Following your explanation, the dialog must be finished, but the transaction 
> from re-INVITE doesn't. Then, the re-INVITE will be retransmited and the UA 
> which has sent the BYE will still answer after the dialog had been finished.
>
> Anyway, I know the dialog and the transactions will be finished, the question 
> is when. Moreover, in some cases it will flood the network unnecessarily.
>
> If I was not so clear, I meant "As the BYE terminates all transactions, " as 
> "As the BYE terminates all transactions of the associated established dialog".
>
> Thanks.
>
>
> Leonardo
>
>
> 
> De: Paul Kyzivat
> Para: sip-implementors@lists.cs.columbia.edu
> Enviadas: Quarta-feira, 3 de Agosto de 2011 14:37
> Assunto: Re: [Sip-implementors] BYE before call answer
>
> On 7/27/11 8:29 AM, Leo Leo wrote:
>>>> Interesting, never thought about it. So, if I send a re-INVITE for
>>>> which I have no final reply yet and then I send a BYE, should the UAS
>>>> reply 200 for the BYE and terminate the remaining re-INVITE
>>>> transasction without sending a final response?
>>
>>>> Or should the UAS reply a "491 Request Pending" for the BYE? Anyhow
>>>> section 14.2 in RFC 3261 just indicates that 491 is useful when there
>>>> is a pending re-INVITE from A to B and B sends a re-INVITE to A. In
>>>> that case A should reply 491.
>> A re-INVITE must not be forked, as RFC says in section 14. Then, no BYE 
>> might come for a re-INVITE. The BYE shall be understood in order to finish 
>> the dialog itself. The CANCEL must be used in that case.
>
> It doesn't matter if the reinvite is forked. A reinvite doesn't
> establish an early dialog, because there is already a final dialog.
> And you may send a BYE within the dialog, regardless of whether there is
> a reinvite outstanding or not.
>
>>>> The unique transaction which remains is the BYE transaction for sending 
>>>> another 200 OK for some retransmission.
>>>>
>>>>
>> Although, the UAC may send some final response (i.e. 487) before
>> sending the 200 OK for the BYE. In matter fact, there is some
>> homologating procedures whi

Re: [Sip-implementors] BYE before call answer

[Paul Kyzivat]

On 8/3/11 1:48 PM, Iñaki Baz Castillo wrote:
> 2011/8/3 Paul Kyzivat:
>> They BYE does *not* "terminate all transactions"!
>> Every transaction must follow its own state machine, independent of any
>> other transaction.
>>
>> You MUST attempt to send some final response to any outstanding
>> transactions even if a BYE transaction has been completed.
>>
>> The BYE only ends the Invite-dialog-usage.
>
> Thanks for clarifying it.

You are welcome.

Further, if you have a dialog with an invite-dialog-usage and a 
subscribe usage (e.g. because you have done a REFER in-dialog), then BYE 
also does not terminate the subscription. There must be a suitable 
NOTIFY to terminate the subscription.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] BYE before call answer

[Paul Kyzivat]

On 7/27/11 8:29 AM, Leo Leo wrote:
>>> Interesting, never thought about it. So, if I send a re-INVITE for
>>> which I have no final reply yet and then I send a BYE, should the UAS
>>> reply 200 for the BYE and terminate the remaining re-INVITE
>>> transasction without sending a final response?
>
>>> Or should the UAS reply a "491 Request Pending" for the BYE? Anyhow
>>> section 14.2 in RFC 3261 just indicates that 491 is useful when there
>>> is a pending re-INVITE from A to B and B sends a re-INVITE to A. In
>>> that case A should reply 491.
> A re-INVITE must not be forked, as RFC says in section 14. Then, no BYE might 
> come for a re-INVITE. The BYE shall be understood in order to finish the 
> dialog itself. The CANCEL must be used in that case.

It doesn't matter if the reinvite is forked. A reinvite doesn't 
establish an early dialog, because there is already a final dialog.
And you may send a BYE within the dialog, regardless of whether there is 
a reinvite outstanding or not.

>>> The unique transaction which remains is the BYE transaction for sending 
>>> another 200 OK for some retransmission.
>>>
>>>
>   Although, the UAC may send some final response (i.e. 487) before
> sending the 200 OK for the BYE. In matter fact, there is some
> homologating procedures which requires this behaviour.
>
>> If the BYE is supposed to "magically" terminate all the pending
>> transactions within the dialog (without requiring a final response for
>> them) then I see no reason to send a 487 (maybe it would fail as the
>> UAC would already terminate the client transaction for the initial
>> INVITE).
>
> As the BYE terminates all transactions, it not really necessarilly. However, 
> it is desired to send the final response in order to avoid retransmissions or 
> unexpectable behavour . I think that's why some homologating procedures 
> requires that. Sending the final response (i.e.487) before 200 OK is reliable.

They BYE does *not* "terminate all transactions"!
Every transaction must follow its own state machine, independent of any 
other transaction.

You MUST attempt to send some final response to any outstanding 
transactions even if a BYE transaction has been completed.

The BYE only ends the Invite-dialog-usage.

Thanks,
Paul


> Leonardo
>
>
> 
> De: Iñaki Baz Castillo
> Para: Leo Leo
> Cc: 
> "sip-implementors@lists.cs.columbia.edu"
> Enviadas: Quarta-feira, 27 de Julho de 2011 9:03
> Assunto: Re: [Sip-implementors] BYE before call answer
>
> 2011/7/27 Leo Leo:
>> Anyway, the RFC says that a receiving BYE must to finish all transactions of 
>> the associated dialog.
>
> Interesting, never thought about it. So, if I send a re-INVITE for
> which I have no final reply yet and then I send a BYE, should the UAS
> reply 200 for the BYE and terminate the remaining re-INVITE
> transasction without sending a final response?
>
> Or should the UAS reply a "491 Request Pending" for the BYE? Anyhow
> section 14.2 in RFC 3261 just indicates that 491 is useful when there
> is a pending re-INVITE from A to B and B sends a re-INVITE to A. In
> that case A should reply 491.
>
>
>> The unique transaction which remains is the BYE transaction for sending 
>> another 200 OK for some retransmission.
>>
>> Although, the UAC may send some final response (i.e. 487) before sending the 
>> 200 OK for the BYE. In matter fact, there is some homologating procedures 
>> which requires this behaviour.
>
> If the BYE is supposed to "magically" terminate all the pending
> transactions within the dialog (without requiring a final response for
> them) then I see no reason to send a 487 (maybe it would fail as the
> UAC would already terminate the client transaction for the initial
> INVITE).
>
>
> Interesting topic :)
>
> Regards.
>
>
>
>
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Broadsoft extensions - event packages talk and hold

[Paul Kyzivat]

On 7/14/11 10:13 AM, Olle E. Johansson wrote:
>
> 14 jul 2011 kl. 16.11 skrev Iñaki Baz Castillo:
>
>> 2011/7/14 Olle E. Johansson:
 I assume it's just a private/custom vendor specification working on
 its own devices (and just that).
>>> No, many vendors use it. And if it was private, shouldn't they use x-talk 
>>> and x-hold ?
>>
>> Using x- for private extensions is a pain, check:
>>
>>   http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful-01
>>
>> Basically, in HTTP world many extensions started as private extensions
>> with x-. Later when they become estandard the x- prefix is removed,
>> but many implementations must now allow both of them.
>>
> Agreed - so Broadsoft should really have registered these names. That's easy 
> enough todo even if you don't want to work yourself through the RFC 
> standardization process.

Yes. But then they would have had to define them as legitimate event 
packages, conforming to 3265.

Thanks,
Paul

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] [Sip] Codec Negotiation and renegotiataion

[Paul Kyzivat]

On 7/14/11 5:34 AM, atul garg wrote:
> Thanks Paul,
>
> Your inputs made it almost clear to me the ebhaviour of codec
> negotiation. However I have one more interesting question now(came after
> discussion with some guy), like is it possible to have two different
> codecs being used in single RTP session at the same time.

Yes, it is possible to use two at the same time.
The classic example is when one of the is telephone-event, which is used 
in conjunction with another codec.

But certainly it is technically valid to switch among all the codecs 
that are mentioned in both the offer and the answer. (I am however not 
an expert at codec implementation. I realize there may be technical 
issues with switching among codecs in this way. But that isn't 
considered in the offer/answer rules.)

> I mean A
> initiates the call to B with SDp codec offrs( 1, 2, 3) it means that A's
> priority is 1 however it supports 2 and 3 also. Now b also supports (1
> ,2 ,3) but its priority is to have 2 (may be some bandwidth reason or
> quality issue). Now what will be the B's response and further behavior-
>
> Will B send ( 2, 1, 3) or it shall send (1 ,2, 3) -

I guess you are asking what the answer will contain, not what is 
actually transmitted in the media stream?

AFAIK B *SHOULD* honor A's priorities. But that means it might not.
So in reality it could do whatever it wants.

> If ( 2, 1 , 3)-
>
> a) Will this be assumed that A and B are agreed upon 2 OR

No. They are agreed on 2,1,3

> b) A will send update with SDP( 2, 1, 3) OR

It could, but isn't obligated to.

> c) A will Drop this call and send the Invite again with ( 2, 1 3) OR

It could, but that seems like a very bad idea

> d) As they have two streams one is for receiving and other for
> sending(ie logical channels i guess)- and A shall send the RTP using
> codec 2( as B is supposed to receive on this) while B shall send using
> codec 1( as A's priority was 1 and it is supposed to receive on 1)

It could, if its capable of doing so.

You are discussing things that are *not specified* by the standards.
Anything not forbidden is permitted.

Thanks,
    Paul

> Regards
> Atul
>
>
> --- On *Wed, 13/7/11, Paul Kyzivat //* wrote:
>
>
> From: Paul Kyzivat 
> Subject: Re: [Sip] Codec Negotiation and renegotiataion
> To: s...@ietf.org
> Date: Wednesday, 13 July, 2011, 10:31 PM
>
> On 7/13/11 11:29 AM, atul garg wrote:
>  > Hello All,
>  > I have very basic question regarding the codec negotiation in SIP, I
>  > will try to summarize my queries below -
>  > 1) If A is initiating the call and sending the supported codec
> list say
>  > (1,2,3)
>  > A --> INVITE (SDP-> audio 1 2 3) --> B ( B supports 1 , 3, 5)
>  > A <-- 200 OK ( SDP -> what will be here 1, 2 ,3 OR 1, 3, 5) <-- B
>  > if it is 1, 3, 5 then what will be the response to B ??
>
> The answer could include 1; 1,3; 1,3,5; or I suppose 1,5; 3,5.
>
> A doesn't "respond" to B.
> If the answer contains both 1,3 then A could use either 1, 3, or
> both when sending to B, and B can use either 1, 3, or both when
> sending to A.
> So if B only wants to use one codec it would be well advised to only
> mention one in the answer.
>
> If B mentioned codec 5, it isn't really useful immediately. Its just
> an FYI for A. It could be treated as a hint, in case A does support
> 5 and just didn't mention it.
>
>  > 2) If A is initiating the call and sending the supported codec
> list say
>  > (1,2,3)
>  > A --> INVITE (SDP-> audio 1 2 3) --> B ( B supports 2 , 3, 5)
>  > A <-- 200 OK ( SDP -> what will be here 2 , 3 OR 2 , 3, 5) <-- B
>  > if it is 2 , 3 then what will be the response to B ??
>  > if it is 2 , 3, 5 then what will be the response to B ??
>
> This isn't much different from (1).
> B could answer with any of the things you say.
>
>  > 3) If A is initiating the call and sending the supported codec
> list say
>  > (1,2,3)
>  > A --> INVITE (SDP-> audio 1 2 3) --> B ( B supports 4, 5,6)
>  > A <-- 200 OK ( SDP -> what will be here ??) <-- B
>
> Typically B would respond with 488.
> If it wants, it could respond 200 and refuse the media stream (port 0).
> That is probably not a good idea unless it has further plans - e.g.
> to make another offer of some sort.
>
>  > and what will be the d behaviour of A 
>
> If the response is 488, A gives up.
> If response is 200 with refused media, it might want to wait and 

Re: [Sip-implementors] Subsequent NOTIFY's within a dialog

[Paul Kyzivat]

On 7/11/11 6:42 AM, Brett Tate wrote:
>> Is it OK to send a subsequent NOTIFY in a SUBSCRIBE initiated
>> dialog, before receiving a successful response for the earlier
>> NOTIFY request?
>
> Yes; unless specifically restricted by the event package, 
> draft-ietf-sipcore-event-rate-control, or similar RFC.
>
> However doing so can complicate some things such as retargeting.

Building on what Brett has said...

If you send a subsequent notify before having received the response to 
the prior one, the subsequent one may be received *before* the earlier 
one. Or the earlier one may never be received at all. If the new one is 
received *before* the earlier one, then the earlier one will be rejected 
with a 500 response, and so not processed.

You should consider the implications of that when deciding whether to 
wait before sending or not. This is primarily a function of the design 
of the event package. If the new event renders the earlier one moot, 
then its fine to do this. If all events must be processed in order, the 
its not fine.

Thanks,
Paul

>> Does the specification mention otherwise?
>
> The following indicates how to respond when such behavior leads to the 
> requests being delivered out of order.
>
> RFC 3261 section 12.2.2: "If the remote sequence number was not empty, but 
> the sequence number of the request is lower than the remote sequence number, 
> the request is out of order and MUST be rejected with a 500 (Server Internal 
> Error) response."
>
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Suggesting what streams to use on call transfer

[Paul Kyzivat]

Inline

On 7/7/11 11:10 AM, Saúl Ibarra Corretgé wrote:
> Hi,
>
> On Jul 7, 2011, at 3:19 PM, Paul Kyzivat wrote:
>
>> AFAIK there is nothing written specifically about this subject.
>> Some thoughts:
>>
>> - when in doubt, the "obvious" thing to do is to offer whatever
>>you would have if you received an invite without offer.
>>
>> - "more is better" - offering as much as you willing and
>>capable of handling will give the recipient the maximal options
>>to select what it wants.
>>
>> - this may be tempered in cases where it is costly to you to
>>offer something. I guess this would be determined by policy.
>>
>> - in a "Replaces" case, if the replaced dialog is using media
>>that you would otherwise not offer by policy, you may want to
>>override the policy and offer them.
>>
>> None of the above requires the REFER to carry anything new.
>>
>
> Agreed. By "policy" do you mean local policy, right?

Yes.

>> The cases where there may be some value in the REFER carrying some "hints":
>>
>> - you want the referred dialog to offer *less* than it normally would.
>>(This could happen in the splices context, where you might want a
>>device to offer video and not audio.)
>>
>> - you want the offer to include media that its policy would normally
>>exclude. (E.g. video was not already in use, and the device normally
>>doesn't offer video by policy unless the local user of the device
>>does something overt to enable video.)
>>
>> I don't think those cases are compelling, so I'm in no rush to work on a
>> mechanism to deal with them.
>>
>
> I don't think video is a good example, because in most cases it goes together 
> with audio, more below.
>
>> Even in normal calling ISTM there is an unexplored area about how to
>> negotiate which media types are used, and how that interacts with user
>> experience. We have been living the simple life where there is generally
>> only one media type (voice) and hence no decisions to be made. But that
>> is now coming to an end.
>>
>
> Indeed!
>
>> Specifically, do video-capable devices offer video whenever they make an
>> initial offer? Or should they wait for the user to manually enable
>> video? If they wait, how would the user know that video is even an
>> option on the call? (There may be a reluctance to establish video by
>> default because the user wants control of when/if his image is seen. And
>> on multifunction devices that share a screen among apps and UI, there
>> may be a reluctance to take screen real estate until its known it is
>> desired.)
>>
>> One solution to that is to offer video, but in recvonly mode initially.
>> Or offer sendrecv but with intent to send video that doesn't originate
>> from the device's camera. (In effect, start with video "muted".) And
>> don't open a window to display video until some is actually received.
>> Instead, have some UI indicators that show the availability of video.
>>
>
> I've seen this implemented as you described in many clients: video is always 
> offered but the stream is either recvonly or inactive and is then toggled. I 
> guess this will save you some bytes in the SDP in case you don't add the 
> stream in the beginning and need to add/remove/add the stream multiple times 
> later.
>
> Consider the following case, the one that made me write the email in the 
> first place: I (Bob) am having a MSRP chat session with Alice. Then Carol 
> calls me with audio. I can do both things at the same time, and I may want to 
> transfer Alice to Carol, but I'd like to suggest Alice that she uses audio in 
> the INVITE she sends to Carol.
>
>> I think there is a fruitful area for investigation here.
>>
>
> I'd be willing to collaborate if there is interest on the subject :-)

I see Dale replied as well, with something a little like my comment, but 
different emphasis.

Lets see if there is more interest here.

I might have a bit of time to work on this after the upcoming ietf 
meeting is over. Till then I can continue to discuss via email but can't 
spend much more time than that on it.

I expect this is an area where there should be room for various kinds of 
policy control as a part of UA innovations, but where the basic 
offer/answer approaches may need standardization to ensure that 
interoperation brings reasonable results.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Suggesting what streams to use on call transfer

[Paul Kyzivat]

AFAIK there is nothing written specifically about this subject.
Some thoughts:

- when in doubt, the "obvious" thing to do is to offer whatever
   you would have if you received an invite without offer.

- "more is better" - offering as much as you willing and
   capable of handling will give the recipient the maximal options
   to select what it wants.

- this may be tempered in cases where it is costly to you to
   offer something. I guess this would be determined by policy.

- in a "Replaces" case, if the replaced dialog is using media
   that you would otherwise not offer by policy, you may want to
   override the policy and offer them.

None of the above requires the REFER to carry anything new.

The cases where there may be some value in the REFER carrying some "hints":

- you want the referred dialog to offer *less* than it normally would.
   (This could happen in the splices context, where you might want a
   device to offer video and not audio.)

- you want the offer to include media that its policy would normally
   exclude. (E.g. video was not already in use, and the device normally
   doesn't offer video by policy unless the local user of the device
   does something overt to enable video.)

I don't think those cases are compelling, so I'm in no rush to work on a 
mechanism to deal with them.

Even in normal calling ISTM there is an unexplored area about how to 
negotiate which media types are used, and how that interacts with user 
experience. We have been living the simple life where there is generally 
only one media type (voice) and hence no decisions to be made. But that 
is now coming to an end.

Specifically, do video-capable devices offer video whenever they make an 
initial offer? Or should they wait for the user to manually enable 
video? If they wait, how would the user know that video is even an 
option on the call? (There may be a reluctance to establish video by 
default because the user wants control of when/if his image is seen. And 
on multifunction devices that share a screen among apps and UI, there 
may be a reluctance to take screen real estate until its known it is 
desired.)

One solution to that is to offer video, but in recvonly mode initially. 
Or offer sendrecv but with intent to send video that doesn't originate 
from the device's camera. (In effect, start with video "muted".) And 
don't open a window to display video until some is actually received. 
Instead, have some UI indicators that show the availability of video.

I think there is a fruitful area for investigation here.

Thanks,
Paul

On 7/7/11 5:55 AM, Saúl Ibarra Corretgé wrote:
>
> On Jul 7, 2011, at 11:48 AM, Iñaki Baz Castillo wrote:
>
>> 2011/7/7 Saúl Ibarra Corretgé:
>>> When doing a call transfer, the party sending the REFER communicates the 
>>> URI the recipient is supposed to call by using the Refer-To header. This 
>>> header may also contain Replaces, in order to indicate that a dialog should 
>>> be "replaced". Is there a standard mechanism to communicate *what* streams 
>>> should the recipient use when sending the outbound INVITE?
>>
>> I assume you mean "which *kind* of streas", right? this is: audio,
>> video, MSRP...
>>
>
> Yes, wrong wording.
>
>>
>>> This would let the REFER recipient know if he should offer audio, video, 
>>> MSRP chat or any other kind of stream. Is there any RFC/draft defining this?
>>
>> I assume that in case I've established a dialog with you and
>> negotiated audio and msrp, then in case you send me a REFER I would
>> generate my new INVITE with offering the same kind of streams. I see
>> the utility of what you mean however.
>>
>
> Indeed, this is the use case that came to my mind.
>
>> PS: I don't know such spec (if it exists).
>>
>
> I hope it does, I don't like the idea of implementing custom behavior :-S
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[Sip-implementors] test

[Paul Kyzivat]

please ignore
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Re-Invite codec renegotiation.

[Paul Kyzivat]

On 7/1/2011 5:12 PM, Kevin P. Fleming wrote:
> On 07/01/2011 02:24 PM, Worley, Dale R (Dale) wrote:
>>> From: Johnson, Michael A [michael.a.john...@team.telstra.com]
>>>
>>> The PBX (Mitel) that sends the re-invite without SDP, that then
>>> accepts the offered G.729 codec from the ISP, despite not being able
>>> support the codec is the device I believe is as fault. The
>>> manufacturer however disagrees.
>>
>> You're still not being clear, but it's clear enough that I can
>> understand what you're talking about.  You are saying:
>>
>>   The PBX sends an re-INVITE without SDP.
>>
>>   The ISP sends a 200 response with SDP.
>
> If I'm following correctly, this offer includes G.729 and G.711.
>
>>   The PBX "accepts" this response (in some manner that you don't
>>   describe) and sends ACK.
>
> The PBX includes an SDP answer in this ACK (as it must), but incorrectly
> (because of its own limitations) includes G.729 in the answer.
>
>>
>>   You consider this to be a fault on the part of the PBX, but you
>>   don't specify why.
>>
>> I believe your misunderstanding is in regard to the PBX sending the
>> ACK.  The PBX does not "accept" the 200 response.  It receives the 200
>> response and *must* then send an ACK.  There is no way for it to
>> "reject" the response.  (This has been discussed in many contexts,
>> which I'm too lazy to look up right now.)
>
> I would think that if the PBX only included G.711 in its SDP answer
> (included in the ACK), all would be well.
>

That would seem to be the case.

The PBX is not "wrong" it what it is doing, but it is *stupid* and 
counterproductive.

Having accepted the the offer, it is generally obligated to accept or 
ignore the incoming packets. It is not obligated to send any, even if 
the stream is sendonly or sendrecv. It is not obligated to play the 
received packets out to its user. (It can't if it doesn't support the 
codec.)

(I guess in this case it is being a music on hold server, and so would 
otherwise send media.)

This is a quality of implementation issue, rather than a protocol issue.
Presumably what you are complaining about is that you want to hear music 
on hold, and you are getting silence instead. (Is that right?)

Presumably the customers of this PBX should be annoyed that their 
callers aren't getting music on hold. I guess they are complaining to 
the SP, and now the question is: who should fix this. Right?

Obviously there are a number of fixes:
- the PBX could include an offer in its invite, with the codecs
   it actually supports

- the PBX could, as mentioned in this thread, return an answer that
   only includes G.711, since that is all it supports in this context.

- the SP could somehow infer that it should only offer G.711, even
   though it also supports G.729.

While the latter would fix the problem, it would lead to other problems. 
How would it decide to do this? I guess it could restrict its offer to 
the codec in use prior to the reinvite. (I've lost track, but I thought 
the problem was that G.729 was in use for the active call, but isn't 
supported by the MOH server. If so, that isn't a solution.)

The problem is that doing so is only a good thing in this one particular 
case. There are other call flows that start out the same, that will 
*break* if all the supported codecs aren't returned in the offer.

IMO, based on my limited understanding of this case, the PBX has nobody 
but itself to blame for the MOH not working.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Forwarding SIP calls between SIP carriers using ENUM

[Paul Kyzivat]

You will have to give more details before any sort of answer is 
possible. Some things to specify:

- Does each account have a distinct phone number?
- what sort of peering is there between the carriers?
- how (if at all) is enum used by each carrier?
- what sort of enum are you talking about?
   (public, carrier, ...)
- what sort of client(s) are you presuming?
- how do the clients connect to the carriers?
- do the clients use enum?

Thanks,
Paul

On 6/29/2011 4:18 AM, mosbah abdelkader wrote:
> Hi,
>
> If a SIP user has 2 SIP accounts: SIPacc1 and SIPacc2 within 2 SIP carriers:
> CARR1 and CARR2. How to use ENUM to forward calls destined to SIPacc1 to
> SIPacc2.
>
> Any other solution is welcome except SIP trunking which requires registering
> each SIP account as a SIP client which will decrease the performance if the
> number of clients is big.
>
> Please help.
>
> Thank you.
>
> --
> Best Regards
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] 18x response after OA complete?

[Paul Kyzivat]

Please read 
http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-18.txt, and 
try to understand it before asking more questions like this.

I gave you this reference earlier. I'm pretty certain that all the 
questions you have asked are dealt with there.

Thanks,
Paul

On 6/29/2011 4:25 AM, Nauman Sulaiman wrote:
> Thank you. However can you confirn no more OA cycles can take place
> using the 18x and PRRACK response after the first one
>
> --- On Wed, 29/6/11, Kumar Verma, Sunil (Sunil)  wrote:
>
>> From: Kumar Verma, Sunil (Sunil)
>> Subject: RE: [Sip-implementors] 18x response after OA complete?
>> To: nauman762-h...@yahoo.co.uk, sip-implementors@lists.cs.columbia.edu
>> Date: Wednesday, 29 June, 2011, 7:43
>> Yes, it is allowed.
>> If you see proxy and other entity, they need 18x response
>> to retain the
>> transaction(Timer C).
>>
>> Regards
>> Sunil Verma
>>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu
>> [mailto:sip-implementors-boun...@lists.cs.columbia.edu]
>> On Behalf Of
>> Nauman Sulaiman
>> Sent: Wednesday, June 29, 2011 4:16 AM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: [Sip-implementors] 18x response after OA
>> complete?
>>
>> Hi,
>>
>> After OA is complete is it possible for UAS to send more
>> 18x responses
>> (with no offer or answer of course).
>>
>> UAC
>>   UAS
>> |INVITE-->|
>> |
>> |
>> |<1xx (o)-| -
>> provisional responses with REQUIRE 100rel
>> |
>> |
>> |-PRACK(a)--->| -
>> send PRACK with answer
>> |<
>> 2xx|
>> |
>> |
>> |
>> |
>> |
>> |<18x | - is
>> this 18x allowed even though OA
>> complete?
>> |
>> |
>> |-PRACK-->|
>> |<2xx-|
>>
>>  200OK
>>
>> <-
>> -->
>>  ACK
>>
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] 18x response after OA complete?

[Paul Kyzivat]

On 6/28/2011 6:46 PM, Nauman Sulaiman wrote:
> Hi,
>
> After OA is complete is it possible for UAS to send more 18x responses (with 
> no offer or answer of course).

YES.

> UAC   UAS
> |INVITE-->|
> | |
> |<1xx (o)-| - provisional responses with REQUIRE 100rel
> | |
> |-PRACK(a)--->| - send PRACK with answer
> |< 2xx| |
> | |
> | |
> |<18x | - is this 18x allowed even though OA complete?
> | |
> |-PRACK-->|
> |<2xx-|
>
>  200OK
> <-
> -->
>  ACK
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Answer in 200OK following answer in 18X rel

[Paul Kyzivat]

On 6/28/2011 6:14 AM, Harbhanu wrote:
>>> If you returned answer in a reliable provisional response, you are
>>> permitted to include a copy of that answer in the 200, but you are
>>> encouraged to *not* do so.
>
> IMO the mentioned scenario violate the 3261 text mentioned below-
>   Once the UAS has sent or received an answer to the initial
>   offer, it MUST NOT generate subsequent offers in any responses to
> the   initial INVITE.

The tricky point here is whether, once an answer has been returned in a 
reliable provisional, SDP in the 200 is an offer, or just redundant.

What we have concluded, in synthesis of all the relevant RFCs, is that 
SDP can be there but does not constitute an offer. Clearly the RFCs 
could have been worded more clearly.

> Also, going by the below text, subsequent answer may be ignored in UAC.
>   The UAC MUST treat the first session description it receives as the
> answer, and MUST ignore any session descriptions in subsequent
> responses to
> the initial INVITE.

Exactly. That text is most relevant for unreliable provisionals, but it 
isn't limited to those - it applies to reliable ones too. That is why 
this is confusing.

Thanks,
Paul

> Please correct if I am missing anything here. Thanks!
>
> Regards,
> Harbhanu
>
> 
> ***
> This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul
> Kyzivat
> Sent: Tuesday, June 28, 2011 3:44 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Answer in 200OK following answer in 18X rel
>
> See http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-18.txt
>
> Bottom line is:
>
> If you returned answer in a reliable provisional response, you are
> permitted to include a copy of that answer in the 200, but you are
> encouraged to *not* do so.
>
> The UAC must be prepared for it to be there.
>
>   Thanks,
>   Paul
>
>
> On 6/27/2011 5:58 PM, Nauman Sulaiman wrote:
>> Hi,
>>
>> In the flow below
>>
>> UAC  UAS
>> >
>>INVITE(0) require 100rel
>>
>> <
>>   183 rel (a)
>>
>> ->
>>PRACK
>> <-
>>200OK
>>
>> <-
>>   200K(a) ??
>> -->
>>ACK
>>
>>
>> after sending answer in 183 rel to INVITE, should the UAS send an answer
>> in the 200OK to the INVITE for widest interoperability or is it best to
> leave it out. Here the OA is complete but I have seen some 3pcc sending
> 200OK with answer in this scenario. Is this optional then?
>>
>> Does UAC need to prepare to handle this 200OK answer and just ignore it?
>> Or should it not be happening.
>>
>> Thanks
>>
>>
>>
>>
>>
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] no supported header in re-invite or different value

[Paul Kyzivat]

Is there a question here?

Paul

On 6/28/2011 4:31 AM, Ravi Kumar wrote:
> Thank to Paul and Brett for reply.
>
>
> - session-timer negotiation is repeated in every reinvite and
> update. If it is not renegotiated to be on, then it is off.
> So in both your cases the session timer stops at the completion
> of the reinvite transaction.
>
> If Re-Invite request does not carry supported: timer, than UAS can not have
> refresher as UAC in response.
> Refer to below text from RFC.
>
> As per RFC 4028
>
> UAC supports?  refresher parameter  refresher parameter
> in request   in response
> ---
>   Nnone uas
>
>
>
> 
> 
>   This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul
> Kyzivat
> Sent: Wednesday, June 22, 2011 10:13 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] no supported header in re-invite or
> different value
>
> Ravi,
>
> - there is *no* semantic difference between a Supported header
> that *doesn't* contain "timer" and the total absence of a
> Supported header.
>
> - session-timer negotiation is repeated in every reinvite and
> update. If it is not renegotiated to be on, then it is off.
> So in both your cases the session timer stops at the completion
> of the reinvite transaction.
>
> - a use case where renegotiation of session timer might make
> sense is when there is a B2BUA in the middle and it does
> a 3pcc transfer. But it doesn't really matter if there is a
> use case, this is how it works.
>
>   Thanks,
>   Paul
>
> On 6/22/2011 2:25 AM, Ravi Kumar wrote:
>> Hi All,
>>
>>
>>
>> 1.
>>
>>
>>
>> CallerCallee
>>
>>
>>
>>
>>
>> -INVITE>
>>
>>   supported: timer
>>
>>   Session-Expires: 200
>>
>>
>>
>>
>>
>> <---200(INVITE)---
>>
>>  supported: timer
>>
>>  Session-Expires: 200;refresher=uac
>>
>>
>>
>> ---ACK-->
>>
>>
>>
>>
>>
>>
>>
>> -INVITE>// Here callee should assume
> that
>> peer supports session timer or not because supported: timer is not present
>> in request.
>>
>>
>>
>>
>>
>> 2.
>>
>>
>>
>> CallerCallee
>>
>>
>>
>>
>>
>> -INVITE>
>>
>>   supported: timer
>>
>>   Session-Expires: 200
>>
>>
>>
>>
>>
>> <---200(INVITE)---
>>
>>  supported: timer
>>
>>  Session-Expires: 200;refresher=uac
>>
>>
>>
>> ---ACK-->
>>
>>
>>
>>
>>
>>
>>
>> -INVITE>// Here callee should assume
> that
>> peer does not support session timer
>>
>>   supported: 100rel
>>
>>
>>
>>
>>
>>
>>
>>   a. Please let me know what should be correct behavior for
> above
>> both cases. And other SIP stack has implemented this.
>>
>>   b. Application scenario where supported value is changed in
>> between the session.
>>
>>
>>
>>
>>
>> Thanks&   Regards,
>>
>> Ravi Kumar
>>
>>
>>
>>
>>
>>
> 
>> 
>>This e-mail and attachments co

Re: [Sip-implementors] Answer in 200OK following answer in 18X rel

[Paul Kyzivat]

See http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-18.txt

Bottom line is:

If you returned answer in a reliable provisional response, you are 
permitted to include a copy of that answer in the 200, but you are 
encouraged to *not* do so.

The UAC must be prepared for it to be there.

Thanks,
Paul


On 6/27/2011 5:58 PM, Nauman Sulaiman wrote:
> Hi,
>
> In the flow below
>
> UAC  UAS
> >
>   INVITE(0) require 100rel
>
> <
>  183 rel (a)
>
> ->
>   PRACK
> <-
>   200OK
>
> <-
>  200K(a) ??
> -->
>   ACK
>
>
> after sending answer in 183 rel to INVITE, should the UAS send an answer
> in the 200OK to the INVITE for widest interoperability or is it best to leave 
> it out. Here the OA is complete but I have seen some 3pcc sending 200OK with 
> answer in this scenario. Is this optional then?
>
> Does UAC need to prepare to handle this 200OK answer and just ignore it?
> Or should it not be happening.
>
> Thanks
>
>
>
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Reinvite Offer Answer - can previous negotiated codec change?

[Paul Kyzivat]

inline

On 6/24/2011 7:26 PM, Nauman Sulaiman wrote:
> Hi,
>
> Just wondering what is preferred here?
>
> UA1 offers  PCMU, PCMA, G729  (PCMU most preferred) to UA2
>
> UA2 answers with PCMU
>
> This completes OA and PCMU is negotiated codec
>
> Then UA2 is put on hold and then unheld

you don't say what was offered and answered for hold.
For now I'll assume its the same as o/a 1.

> UA2 sends in REINVITE (Unhold) offer  G729,PCMA,PCMU  (G729 most preferred)
>
> As G729 is preferred codec, UA1 answers with only G729 and negotiated codec 
> has been changed.
>
> What is best here, should UA1 answer with PCMU here as this was what was
> negotiated in first OA (in effect it remembers )
>
> OR should it just answer with G729 as this is the preferred codec sent in 
> offer by UA2. So here it does not care what was previously negotiated.

IMO either is ok - take your pick.

But in general, for o/a, I recommend that each party always go with its 
own preferences, to the extent permitted by the o/a rules. When one side 
makes assumptions about what the other side wants, that can lead to 
mistakes - sometimes nasty ones.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Regarding 'Supported' and 'Require'

[Paul Kyzivat]

Supported and Require are not formally linked.
For some options you can infer a logical connection.
When in doubt, be explicit.

Also note that Require:xyz means "I require you to *support* xyz". It 
does not mean "I require you to *use* xyz" or "I intend to use xyz".

Thanks,
Paul

On 6/24/2011 1:34 AM, Harbhanu wrote:
> Hi,
> As per 3261, the text for Supported and Require is as below-
>
> Supported:
> If the UAC supports extensions to SIP that can be applied by the
> server to the response, the UAC SHOULD include a Supported header
> field in the request listing the option tags (Section 19.2) for those
> extensions.
>
> Require:
> If the UAC wishes to insist that a UAS understand an extension that
> the UAC will apply to the request in order to process the request, it
> MUST insert a Require header field into the request listing the
> option tag for that extension.
>
> Is it valid to interpret that an extension present in 'Require' is also
> 'Supported' by
> the UAC?
> In other words, is it mandatory to put an extension in both headers, incase
> 'Require' is used for any extension?
> This becomes bit confusing, since any Proxy 'MAY' put 'Require' in the
> message.
>
> As per my opinion these two should be explicitly carry the extension,
> because of the proxy case.
>
> Please share your opinion. Thanks!
>
> Regards,
> Harbhanu
>
>
> 
> ***
> This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Is PRACK and UPDATE mandatory in some use cases

[Paul Kyzivat]

On 6/22/2011 12:40 PM, Nauman Sulaiman wrote:
> Hi
>
> Some UAs do not support PRACK or UPDATE and still work fine with various 
> Proxies, PBX, Softswitches etc. Are there any scenarios or well known 
> Proxies,Softswitches that require mandatory PRACK and UPDATE support for a UA 
> to be interoperable? Or maybe some features will not be available if support 
> for these methods is not there.
>
> Just trying to understand where PRACK and UPDATE are used.

Its been a *really* long time since 3262 and 3311 were published. There 
is no reason for UAs not to support PRACK and UPDATE.

There are devices/systems with constraints that may make it necessary to 
to multiple (typically 2) offer/answer exchanges before establishing a 
call.

The use case that initially motivated PRACK was QoS, but that is not the 
only one. For instance there are some UAsthat can only support one codec 
at a time. Such a UA will offer multiple codecs because it doesn't know 
which ones the answerer can support. But then if the answerer answers 
with multiple codecs, there is need of another o/a cycle to select one 
from among those common to offer and answer.

(However this is often handled without a second o/a, using "wishful 
thinking" to assume that only the first of the codecs in the answer will 
actually be used. I guess if others are then used it just doesn't work.)

Thanks,
Paul

> Thanks
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] no supported header in re-invite or different value

[Paul Kyzivat]

Ravi,

- there is *no* semantic difference between a Supported header
   that *doesn't* contain "timer" and the total absence of a
   Supported header.

- session-timer negotiation is repeated in every reinvite and
   update. If it is not renegotiated to be on, then it is off.
   So in both your cases the session timer stops at the completion
   of the reinvite transaction.

- a use case where renegotiation of session timer might make
   sense is when there is a B2BUA in the middle and it does
   a 3pcc transfer. But it doesn't really matter if there is a
   use case, this is how it works.

Thanks,
Paul

On 6/22/2011 2:25 AM, Ravi Kumar wrote:
> Hi All,
>
>
>
> 1.
>
>
>
> CallerCallee
>
>
>
>
>
> -INVITE>
>
>  supported: timer
>
>  Session-Expires: 200
>
>
>
>
>
> <---200(INVITE)---
>
> supported: timer
>
> Session-Expires: 200;refresher=uac
>
>
>
> ---ACK-->
>
>
>
>
>
>
>
> -INVITE>   // Here callee should assume that
> peer supports session timer or not because supported: timer is not present
> in request.
>
>
>
>
>
> 2.
>
>
>
> CallerCallee
>
>
>
>
>
> -INVITE>
>
>  supported: timer
>
>  Session-Expires: 200
>
>
>
>
>
> <---200(INVITE)---
>
> supported: timer
>
> Session-Expires: 200;refresher=uac
>
>
>
> ---ACK-->
>
>
>
>
>
>
>
> -INVITE>   // Here callee should assume that
> peer does not support session timer
>
>  supported: 100rel
>
>
>
>
>
>
>
>  a. Please let me know what should be correct behavior for above
> both cases. And other SIP stack has implemented this.
>
>  b. Application scenario where supported value is changed in
> between the session.
>
>
>
>
>
> Thanks&  Regards,
>
> Ravi Kumar
>
>
>
>
>
> 
> 
>   This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it
>
>
>
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Wrong SIP scheme and/or URI transport param

[Paul Kyzivat]

On 6/9/2011 4:08 AM, Iñaki Baz Castillo wrote:
> 2011/6/9 Paul Kyzivat:
>> On 6/8/2011 3:50 PM, Iñaki Baz Castillo wrote:
>>
>>> Some existing proxies reply some custom 4XX codes for these kind of
>>> errors. I would like some specific and standarized 4XX response code,
>>> something like:
>>>
>>>467 "Unsupported Transport"
>>
>> Go for it! Submit a draft. (Send it to the dispatch list.)
>> Put some text clearly explaining the problem and why existing mechanisms
>> don't provide a solution. After that motivation, you can propose the
>> solution.
>
> Thanks Paul, I'll strongly consider doing it. Just a comment before:
> wouldn't be 500/503 a suitable error code in this case? (however I do
> know that 503 is "suitable" in too much cases...).

For an unsupported/unrecognized transport, like sctp, 501 might be a 
reasonable choice. It would be much better than 500 for that case. 500 
could be used if its a *server* problem that you can't find anything 
better for, but like 400 its overly vague.

In the cases of inconsistency (sips with udp) the problem is with the 
request, not the server, and so a 4xx response is more appropriate.

503 is a terrible choice for any of these. It will cause the sender to 
back off on sending requests. Its really only for overload types of 
situations.

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Wrong SIP scheme and/or URI transport param

[Paul Kyzivat]

On 6/8/2011 3:50 PM, Iñaki Baz Castillo wrote:

> Some existing proxies reply some custom 4XX codes for these kind of
> errors. I would like some specific and standarized 4XX response code,
> something like:
>
>467 "Unsupported Transport"

Go for it! Submit a draft. (Send it to the dispatch list.)
Put some text clearly explaining the problem and why existing mechanisms 
don't provide a solution. After that motivation, you can propose the 
solution.

I think such an error code would clearly apply to the transport=sctp 
case with a server that doesn't support sctp.

It a little less clear for the sips over udp case. At the least there 
should be some text in the definition of the code that makes it apply to 
such cases. (And there is also the possibility that sips over udp should 
simply imply DTLS.)

Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors