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

[Paul Kyzivat]

These are indeed fuzzy cases.

IMO, I would treat problems with a URI in a topmost Route header the 
same as a problem with the R-URI when there is no Route header.
(So I think 416 is appropriate for case (d).)

The others don't seem to fit 416 or anything else very well.
So when in doubt, go with 400.

I expect you will get some other, different, opinions.

Thanks,
Paul

On 6/8/2011 10:56 AM, Iñaki Baz Castillo wrote:
> Hi, RFC 3261 says:
>
> 21.4.14 416 Unsupported URI Scheme
>   The server cannot process the request because the scheme of the URI
>   in the Request-URI is unknown to the server
>
> But imagine these requests arriving to a proxy which just can talk SIP
> over UDP/TCP (and TLS over TCP):
>
>
> a) INVITE sips:al...@domain.org;transport=udp
> (note that transport=udp is not valid por sips scheme).

> b) INVITE sips:al...@domain.org;transport=sctp
> (note that proxy does not speak SCTP neither SCTP over TLS)
>
> c) INVITE sips:al...@domain.org;transport=tcp
>  Route:
> (note that proxy does not speak SCTP neither SCTP over TLS)
>
> d) INVITE sip:al...@domain.org
>  Route:
> (note the ugly HTTP URI in Route)
>
>
> Which should be the proxy rejection response in each case?
> Thanks a lot.
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Broadworks Reinvite issue

[Paul Kyzivat]

On 4/28/2011 3:01 AM, Nauman Sulaiman wrote:
> Hi,
>
> Scenario is as follows UAC makes call to UAS over Broadworks B2BUA and then 
> UAC goes on hold. Broadworks periodically issues Session Audit with SDP 
> version number unchanged, this is for UAC and UAS which do not support 
> session timers or UPDATE method.
>
> UAC --->   Broadworks >  UAS
> INVITE ver=1INVITE ver=1
>  sendrecv sendrecv
> UAC<---Broadworks<-- UAS
> 200OK ver=1200OK ver=1
>   sendrecv  sendrecv
>
> UAC goes on hold
>
> UAC>  Broadworks  --->  UAS
> INVITE ver=2INVITE ver=2
>  sendonly inactive
>
> UAC<-Broadworks<-   UAS
> 200OK ver=2  200OK ver =2
>  inactive inactive
>
>
> Broadworks session audit  (UPDATE not supported by UAC or UAS)
>
>
> UAC< Broadworks
>   INVITE ver=2
>inactive
> UAC-->   Broadworks
>   INVITE ver=2
> ??

The UAC has no choice here - it MUST respond as inactive. (That is the 
only valid answer for an offer of inactive.) And that makes the SDP 
different from what was in the one with ver=2, so it will have to be ver=3.

I presume this is what Brett was saying.

Thanks,
Paul

> With session Audit shown at the end, Broadworks sends the UAC a REINVITE with 
> the session version unchanged. However the last SDP that the UAC sent 
> broadworks had a media attribute of sendonly.
>
> What should the UAC send back in the media attribute field here, should SDP 
> be unchanged if the version no. is unchanged but in this case we would send 
> back the original sdp with an attribute of sendonly.
>
> I have seen UAs put inactive in this field,  what is correct?
>
>
> Many 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] Call Transfer Using REFER

[Paul Kyzivat]

On 4/26/2011 1:09 PM, isshed wrote:
> Thanks Dale for your response. so the other doubt is what will happed to
> this dialog when the call gets transferred. does it not get destroyed with
> the BYE? if so what about the rest of the notify?

You should read 5057 on dialog usages - you need to understand that.

When you send a REFER in a dialog with an existing invite-dialog-usage, 
it will cause a subscribe-dialog-usage (for the refer event package) to 
be established in the dialog as well.

These two usages terminate *independently* of one another. The 
invite-dialog-usage will probably end with a BYE when the transfer 
succeeds. But the subscribe-dialog-usage, and hence the dialog, remains 
until you terminate it, with the appropriate NOTIFY message.

In principle you can send a subscribe within an dialog established by an 
INVITE. (This is done by some implementations.) And its conceivable to 
send an INVITE within a dialog established by a SUBSCRIBE, though I have 
never heard of it being done. These sorts of usage have been deprecated, 
because they introduce some nasty error situations.

Thanks,
Paul

> I know I am asking the basics but it will improve my understanding.
>
> Thanks.
>
> On Tue, Apr 26, 2011 at 8:55 PM, Worley, Dale R 
> (Dale)wrote:
>
>> Although it is not mentioned in any of the RFCs, the universal way of using
>> REFER for call transfer is to send the REFER within the dialog that you are
>> transferring, the dialog that was created by the initial INVITE.  "Out of
>> dialog REFER" is rarely used for call transfer.
>>
>> It is very uncommon to have a subscription and an "INVITE dialog usage"
>> (that is, phone call) within the same dialog -- with the exception of the
>> subscription that is created by a REFER within the INVITE dialog usage.
>>
>> 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] No Ringback in 183 SDP

[Paul Kyzivat]

On 4/12/2011 12:21 PM, Randell Jesup wrote:
>> 3 apr 2011 kl. 13.23 skrev Iñaki Baz Castillo:
>>
>>> 2011/3/31 Olle E. Johansson:
 If you are sending only ringback, I would recommend sending 180 with SDP 
 instead of 183. If you're sending 183, I can't move my state machine to 
 ringing state, which would help a lot of 3rd party apps. If you send 
 ringback in 183 - they won't notice the ringing and would see the call 
 going from calling state directly to answer, which is confusing. Sending 
 ringback with 183 and not sending 180 is a problem for many apps.

 Use 183 only if you have an operator message to play. Otherwise, add SDP 
 to the 180 Ringing.
>>>
>>> Hi Olle. So you propose that ringback (just pure ringback with no
>>> voice announcement) should be always sent in a 180 response (with or
>>> without SDP, as usually SIP phones generate 180 with no SDP, of
>>> course).
>> Yes. I am not saying that you should always send ringback with 180, but
>> if you do want to send ringback in audio, use 180.
>
> I should tell you that this is opposite how almost all commercial
> products work; 180 is normally used without SDP for telling the caller
> to generate internal ringback, and 183 with SDP is used for providing
> remote ringback (usually from a SIP->PSTN gateway).  Most UA devices
> don't send ringback themselves and just send 180 to the server.
>
>>> And just use 183 (always with SDP for sure) when the media contains an
>>> announcement ("the number you are calling is not available" and so).
>> exactly.
>>
>>> Am I right?
>> Yes.
>>
>> 183 doesn't say much about the state change, but 180 is actually a
>> state change indicating that something is alerting the target about an
>> incoming call. This is very important in gateway situations, like a
>> b2bua like Asterisk.
>
> A quote from this list from 2008 (use the archives!!!):
>
>  RFC3960 gateway model gives guidelines about the, let's say, "correct"
>  behavior. The main rule says more or less "media has always the 
> precedence".
>  About the scenario you mentioned in the text, i.e. 183/SDP and then 180 
> (no
>  SDP I assume) you should play a local ringback ONLY in the case you don't
>  receive any media (despite the media channel has been established).
>  In the reverse case, i.e. 180/noSDP and the 183/SDP the rule is the same,
>  meaning you should play the media. Should the media missing, you would
>  continue to play the local ringback due to the 180.
>
>  This is what RFC3960 says. In the real world (especially when you
>  interoperate to the PSTN) it doesn't work in some case. My 
> recommendation is
>  to always use the latest received message as the most significant. Then, 
> in
>  the first case once receiving the 180 I would suggest to play a local
>  ringback stopping playing the media, in the second one to stop the local
>  ringback and play the media (if any). Using this approach, I didn't find 
> yet
>  any failing case when interoperating with PSTN (this is the most complex
>  scenario usually) in the operator's network I'm working with.

I don't understand. What is there about the "gateway" model that doesn't 
work in the real world with the PSTN?

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

Re: [Sip-implementors] 482 loop detected.

[Paul Kyzivat]

Is this a trick question?

A *client* never sends responses. The thing that sends (any) response is 
an server.

I guess the question is whether there is any case where a UA can send a 482?

Thanks,
Paul

On 3/30/2011 10:57 AM, Brett Tate wrote:
>> Is there any scenario or use case where a sip client
>> can send 482.
>
> Search rfc3261 for 482.  It discusses sending it for merged requests.
>
>
> ___
> 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] Error after receiving 200OK

[Paul Kyzivat]

On 3/30/2011 3:33 AM, Jyoti Singhal wrote:
> Hi All,
>
> In case if we have received 200 OK to an INVITE request, now due to same
> failure at proxy, proxy wants to end the call --- What should be the
> scenario?

Your case below isn't clear. I presume there is a "proxy" in the middle 
that isn't shown. What led to the 4xx response after receiving a 2xx 
response? (That isn't normal proxy behavior.) From above, you suggest 
some proxy failure. If so, sw or hw?

> Case 1:
>
> INV --->  INV
>  <  200
> 4xx<---
>  ->  ACK
>  ->  BYE
>
> Just wanted to confirm how important is to send an ACK in such situation.
> Can a graceful termination of call by sending a BYE after receiving 200 OK
> is acceptable?

ACK is always required, except in cases where the communication path has 
failed.

Proxies in a dialog are not allowed to originate a BYE in the dialog.

I expect I don't really get your use case. If you can explain it better 
it may be possible to give you a better answer.

Thanks,
Paul

> With Regards,
> Jyoti
> ___
> 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] Different SDP Session Version in 183 & 200 OK

[Paul Kyzivat]

This thread has gone on for a long time. There is some good/accurate 
info and some very wrong info here. This is a complex topic that is 
widely misunderstood. I *strongly* encourage you to read the 
offer-answer draft referenced earlier. It is a compilation of 
information from multiple RFCs and with a lot of 
clarification/interpretation.

I've not kept track entirely, but I think Atilla and Bob have it right.

Bob does give you some pragmatic advice. It technically violates 3261. 
But it is advice for the UAC in a case when the UAS is non-conforming. 
In such cases you are really on your own. What works will depend on what 
the UAS expected when it violated the specs.

A bit more inline below

On 3/11/2011 5:07 AM, Jaiswal, Sanjiv (NSN - IN/Bangalore) wrote:
> Hi Attila,
>
> Take for example the early media is established with
> invite/18x/PRACK/200k(of PRACK).
> Now announcement is played and after that if endpoint want to change the
> media( for established dialog)   then as per you mention , end point has
> to send update with change media  stream. And Sending  200 OK (new offer
> ) and ACK (SDP ) doesn't make any difference.
> Is this correct?

There are a couple of ways to accomplish your objective:

- as you suggest, finish up the INVITE transaction, then do a reINVITE
   or UPDATE with new o/a to switch the media. This all within the same
   dialog.

- a "tricky" way to do this is, after the announcement is done,
   send your new sdp answer in a 200 ok to the INVITE, but with a
   *different* to-tag. This means you had one early dialog for the
   announcement, and a different dialog for the actual call.
   This is entirely legitimate. (But not all UACs will handle it
   properly.)

Thanks,
Paul

> Regards
> Sanjiv
>
> 
>
> From: ext Attila Sipos [mailto:attila.si...@vegastream.com]
> Sent: Friday, March 11, 2011 3:18 PM
> To: Jaiswal, Sanjiv (NSN - IN/Bangalore); ext ashok kumar
> Cc: sip-implementors@lists.cs.columbia.edu; Nitin Kapoor
> Subject: RE: [Sip-implementors] Different SDP Session Version in 183&
> 200 OK
>
>
>
>
> Hi Sanjiv,
>
> The behaviour you describe is not permitted.
>
> As Bob Penfield correctly said:
> There can be only one offer/answer in a single INVITE transaction. There
> can be a second offer/answer exchange on an early dialog (i.e. before
> the 200 on the INVITE), but that second offer/answer must be in a PRACK
> (scenario 5) or UPDATE (scenario 6) and only when the initial answer
> delivered in a reliable provisional response (scenario 3).
>
> Best Regards
>
> Attila
>
>
> -Original Message-
> From: Jaiswal, Sanjiv (NSN - IN/Bangalore)
> [mailto:sanjiv.jais...@nsn.com]
> Sent: Fri 11/03/2011 09:20
> To: ext ashok kumar; Attila Sipos
> Cc: sip-implementors@lists.cs.columbia.edu; Nitin Kapoor
> Subject: RE: [Sip-implementors] Different SDP Session Version in 183&
> 200 OK
>
> Hi Ashok,
>
> The SDP from 183 is considered as Answer of initial offer.
> Different SDP in 200 OK is considered as new offer and then it is must
> to send the ACK with SDP answer for second negotiation to successful.
>
> Regards
> Sanjiv
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext
> ashok kumar
> Sent: Friday, March 11, 2011 1:58 PM
> To: Attila Sipos
> Cc: sip-implementors@lists.cs.columbia.edu; Nitin Kapoor
> Subject: Re: [Sip-implementors] Different SDP Session Version in 183&
> 200 OK
>
> Hi Attila,
>
> Agree with you but what happens when 183 and 200 OK have different SDPs
> from
> the terminating endpoint. Then which SDP should be considered as an
> answer.
> RFC 3261 does not talk about this. And in case of Nitin's scenario, SDPs
> are
> different since session version is incremented (though all other
> contents
> remain same).
>
> Only when the same answer is placed in 18X and 200 then only the SDP in
> 18X
> will be considered as an answer.
>
> Please correct me if I'm wrong.
>
> Thanks,
> Ashok
>
>
> On Wed, Mar 9, 2011 at 7:40 PM, Attila Sipos
> wrote:
>
>> There is a draft which tries to clarify what is legal.
>>
>> http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13
>>
>> OfferAnswer 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
>>  6. UPDATE Req.  2xx UPDATE Resp. RFC 3311  N   YY
>>
>>   Table 1: Summary of SIP Usage of the Offer/Answer Model
>>
>> According to Table 1 it seems that you could be allowed scenario 4
>> follo

Re: [Sip-implementors] ascii encoding

[Paul Kyzivat]

On 3/1/2011 6:03 AM, Nikos Leontsinis wrote:
> I am not sure if implementors are obliged to honour this request.

Implementors are obliged to honor whats written in specs if they want to 
claim compliance to the spec, and to interoperate with other compliant 
implementations.

If you don't care about compliance and interop you can do whatever you like.

Paul

> On 1 March 2011 12:18, Iñaki Baz Castillo  wrote:
>> 2011/3/1 Nikos Leontsinis:
>>> If yes the # key should never be used on the prefix use.
>>
>> Right. # is not allowed in a SIP URI username. However it's valid in a
>> TEL URI, but in case of using # in a SIP URI username it must be
>> hexadecimal encoded.
>>
>> --
>> Iñaki Baz Castillo
>> 
>>
>
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Query on Handling of null ipv6 address in SDP c= line.

[Paul Kyzivat]

DNS isn't my *thing*, but IIUC, couldn't "whatever.invalid" be resolved 
to an FQDN of "whatever.invalid.example.com" if the node doing the 
resolving has "example.com" as its domain?

To be sure, wouldn't it be necessary to specify "whatever.invalid." ???

Thanks,
Paul

On 2/16/2011 8:09 AM, Kevin P. Fleming wrote:
> On 02/16/2011 05:36 AM, Brett Tate wrote:
 The draft also discusses using ".invalid"; however as
 I mentioned within the following link, I not sure if
 that it is really formatted as a valid FQDN.
>>>
>>> For sure ".invalid" is not a valid FQDN.
>>
>> Thanks for the response.  The following is the exact snippet from 
>> draft-ietf-sipping-v6-transition-07 section 4.1.
>>
>> "For this, IPv6 implementations MUST use a domain name within the .invalid 
>> DNS top-level domain instead of using the IPv6 unspecified address (i.e., 
>> ::)."
>>
>> Is the draft currently indicating to use 1) ".invalid", 2) "invalid", 3) 
>> "invalid.", or 4) something like "whatever.invalid"?
>>
>> I think that the answer is number 4; however I don't recall if any of the 
>> others would be good enough to satisfy draft-ietf-sipping-v6-transition, RFC 
>> 4566, and RFC 1035.
>
> It is indeed number 4; I think the text in the draft is fairly clear on
> that point.
>
> Neither 2 or 3 would be 'within the .invalid DNS TLD', and number 1 is
> not "a domain name within the .invalid DNS TLD'.
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Query on Handling of null ipv6 address in SDP c= line.

[Paul Kyzivat]

On 2/11/2011 7:26 AM, Brett Tate wrote:
> Draft-ietf-sipping-v6-transition-07 section 4.1 imposes some offer/answer 
> restrictions which prevents answering IPv6 with IPv4.

OK. I wasn't very familiar with that one.

Thanks,
Paul

> The draft also discusses using ".invalid"; however as I mentioned within the 
> following link, I not sure if that it is really formatted as a valid FQND.
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg07007.html
>
>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat
>> Sent: Thursday, February 10, 2011 5:26 PM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Query on Handling of null ipv6 address
>> in SDP c= line.
>>
>> Adding to what brett said...
>>
>> Why is it necessary to have a separate null address for IPv6?
>> Null is null. Won't an IPv4 null address do? Even if your node doesn't
>> support IPv4, I would think it could support a *null* IPv4.
>>
>>  Thanks,
>>  Paul
>>
>> On 2/7/2011 7:09 AM, Brett Tate wrote:
>>>> What must be done when NULL IPv6 address in received
>>>> in SDP c= line,
>>>
>>> No MUST behavior has been defined for the situation; it is not a
>> hold.
>>>
>>> The UAS received a request to communicate with a non
>> reachable/responsive location.  If the UAS responds prior to the
>> connection attempt, the UAS will likely send a 200 response with SDP
>> reflecting typical offer/answer rules.  The non reachable/responsive
>> location may subsequently cause the call to be released; however the
>> UAS might be more forgiving if some media attributes (such as
>> "inactive" and "sendonly") were used.
>
>
> ___
> 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 Regarding Media port change in 200 OK

[Paul Kyzivat]

I agree with Dale and Brett, sort of.

Brett is right that the UAC is correct in ignoring the change in the 
200. Dale is right that the UAS is wrong in sending different SDP in the 
180 and 200.

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

Thanks,
Paul

On 2/10/2011 12:06 PM, Worley, Dale R (Dale) wrote:
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of 
> bijoy.prak...@wipro.com [bijoy.prak...@wipro.com]
>
> What I want to confirm is that if this behaviour from the 3rd party is
> proper that is changing the media port in 200 OK after sending another
> port in 180 Ringing.
> ___
>
> Assuming that the 180 and 200 have the same to-tag (and so are part of the 
> same early dialog), the behavior is improper.  The SDP in a non-100rel 
> provisional response must be the same as the SDP in the 2xx response.  See 
> RFC 3261 section 13.2.1:
>
>o  If the initial offer is in an INVITE, the answer MUST be in a
>   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.
>
> 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 on Handling of null ipv6 address in SDP c= line.

[Paul Kyzivat]

Adding to what brett said...

Why is it necessary to have a separate null address for IPv6?
Null is null. Won't an IPv4 null address do? Even if your node doesn't 
support IPv4, I would think it could support a *null* IPv4.

Thanks,
Paul

On 2/7/2011 7:09 AM, Brett Tate wrote:
>> What must be done when NULL IPv6 address in received
>> in SDP c= line,
>
> No MUST behavior has been defined for the situation; it is not a hold.
>
> The UAS received a request to communicate with a non reachable/responsive 
> location.  If the UAS responds prior to the connection attempt, the UAS will 
> likely send a 200 response with SDP reflecting typical offer/answer rules.  
> The non reachable/responsive location may subsequently cause the call to be 
> released; however the UAS might be more forgiving if some media attributes 
> (such as "inactive" and "sendonly") were used.
>
>
> ___
> 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] Telephony DTMF adaptation

[Paul Kyzivat]

On 1/31/2011 6:06 PM, Mikko Lehto wrote:

> I fail to understand why DTMF delivery methods in signaling path are not as
> stabilized as RFC 2833/4733 is.
> There are many use cases where nice features can be enabled with events
> while dedicated event detector is not feasible in media path.

History.

Very early on there were proprietary INFO-based DTMF methods.
For fairly good reasons, those techniques were found wanting.
Rather than do another INFO-based mechanism, KPML was defined. But it 
has not never gotten traction. Meanwhile other mechanisms have been 
deployed. Now its to the Tower-of-Babel stage, but any new proposal just 
makes it worse.

A lot of Cisco gear supports at least three mechanisms, (maybe more) 
with transcoding between 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] Query on SDP hold

[Paul Kyzivat]

On 1/19/2011 1:49 PM, Chandan Kumar wrote:
> Hi,
>
>   As per O/A model rfc 3264 re-invite offer with  SDP containing connection 
> IP 0.0.0.0 is  not recommended . Since UA neither send any RTP/RTCP as the 
> destination media address is not known nor receive any RTP/RTCP from 0.0.0.0.

There are good reasons for this recommendation. But it is a 
*recommendation*, not a requirement. And HOLD is a feature. We don't 
actually standardize the implementation of this feature, only mechanisms 
that might be used to accomplish it. If you receive signaling that you 
interpret as being a HOLD, you can't really know that is what it is - 
there may be other reasons motivating that signaling. Using 0.0.0.0 as 
the media address is still a valid thing to do.

> we are facing interop issue with B2BUA  when a re-Invite  offer is recevied 
> with SDP containing c=0.0.0.0 and a=inactive

There are/were UAs that do things this way because it was the most 
certain way to work with both 2543 and 3261 compatible peers. I doubt 
there are any 2543 implementations out there any longer, but this sort 
of behavior tends to linger on.

> Below  is what's happening, after the basic call  is succesfully connected.
> 1)UA1 initiates hold request  with a=inactive ,B2BUA modfies SDP with 
> c=0.0.0.0&  a = inactive ,forward the request to UA2.

You are saying that UA1's offer has a non-zero c=, and the B2BUA 
modifies it to c=0 ?

> 2)UA2 responds with 200ok sdp body with connection IP of its own IP 
> (ex:192.168.1.23)&  a=inactive.

That media address is passed through the B2BUA unchanged to UA1?

> 3)UA1 initiates unhold with a=sendrecv ,B2BUA modfies SDP with c=0.0.0.0&  a 
> = inactive ,forward the request to UA2. Here B2BUA has not sent ACK to UA1

This seems a serious error by the B2BUA. Even without regard to the 
media addresses, changing a=sendrecv to a=inactive is a major issue.

You say B2BUA has not sent ACK to UA1, but it doesn't own an ACK. It 
owes UA1 a response to its INVITE. Is that what hasn't yet been sent?

> 4)UA2 responds with 200 ok with SDP body with connection IP of its own IP 
> (ex:192.168.1.23)&  a=inactive.
>
> 5)B2BUA sends Invite without SDP body for session refreshment.

Did the B2BUA ACK the response from UA2?
It is then sending another INVITE to UA2, without having sent anything 
to UA1?

> 6)UA2 responds 200ok with a=sendrecv&  connection IP of its own.

Good. UA2 is playing nice.

> 7)B2BUA sends ACK with SDP body of connection IP of UA1&  a=sendrecv

OK, at least that makes some sense.

> 8)Now B2BUA sends ACK with SDP body a=sendrecv  to UA1 (this ACK is for point 
> 3).

As noted, B2BUA should be sending response (presumably 200) to UA1, with 
this info. If it did, things would probably work.

If its really sending an ACK, UA1 will probably ignore it, and 
eventually retransmit the INVITE.

> Now UA1&  UA2 are in call,But RTP media flow is not flowing.
>
> Could some one give help in understanding this issue&  how to resolve .

Sending ACK when a 200 is required is a major problem.
The B2BUA actions at step 3 are also a (lesser) problem.

Thanks,
Paul
___
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]

On 1/19/2011 4:13 AM, Sunil wrote:
> Hi All,
>
> Please clarify how to handle the below requirement of rfc 3261in case of
> 3 scenarios: The UAS MUST ensure that the session description overlaps
> with its previous session description in media formats, transports, or
> other parameters that require support from the peer.
>
> 1. User A and User B are in connected state and user A receives a
> re-INVITE without offer. in this case the OFFER sent in 2xx (which is
> expected to be like an initial offer) may vary with the existing ongoing
> session's negotiated parameters. is it ok if user A sends offer with all
> capabilities even if it knows that user B des not support all the
> capabilities.Can user A receive re-INVITE without offer from a proxy??

Not only is it *ok*, it is the optimal thing to do.
It cannot *know* what B supports now. It only knows something of what B 
supported at the last o/a exchange, and even then its knowledge is 
likely incomplete. And there is no harm in offering all capabilities, 
since B can still reject those it currently doesn't support.

This becomes critical in a 3pcc transfer scenario. In that case A is 
really a B2BUA, and is intended to transfer the call to another UA that 
may have entirely different capabilities than those currently in use.

Of course A may choose not to offer all of its capabilities, for its own 
reasons. For instance it may have video capability but choose not to 
offer it because it is operating in no-video mode.

> 2. User A and User B are on HOLD and user A receives a re-INVITE without
> offer. then what should be the direction mode in offer??

Depends on A's local state. If A had previously initiated HOLD, and 
still wants the call on hold, then it should send offer with sendonly 
(or inactive if it doesn't want to send MoH). If A had preferred to be 
sendrecv but is currently in recvonly or inactive due to prior action by 
B, then it should offer sendrecv and let B decide what to respond with. 
(Doing otherwise can result in a "stuck on hold" situation if both ends 
put the call on hold.)

> 3. User A and User B are in a FAX session (which was negotiated through
> re-INVITE after audio session) and user A receives a re-INVITE without
> offer, what shoud the offer contain audio media stream details or fax
> media stream details.

Whatever it prefers. There is no perfect solution here. For dedicated 
fax machines it may make sense to offer fax again.

One solution would be to offer both, as separate m-lines and let the 
other end decide. Or it could use the new SDP capability negotiation 
framework (RFC 5939) to offer one but indicate support for the other as 
well.

> Also if a SIP Stack supports RFC 3407(Session Description Protocol (SDP)
> Simple Capability Declaration) can it override the above requirement
> ie., the offer in 2xx will contain the negotiated media stream and
> include the capability specific attributes which includes all the media
> formats, all parameters etc.

I don't know about 3407 except that it has been superseded by 5939.

Thanks,
Paul

> Many thanks in advance for your precious time..
>
> Regards,
>
> Sunil
>
>
> ___
> 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] draft sipping-v6-transition and SDP offer/answer

[Paul Kyzivat]

On 1/13/2011 10:38 AM, Iñaki Baz Castillo wrote:
> 2011/1/13 Olle E. Johansson:
>> - Does your UA add an SDP to a 488 error message?
>
> Most probably no UA in the world adds SDP to a 488 response.

I don't know, but I suspect you are right, or nearly so.

> And for sure, no UA in the galaxy would inspect/interpret a SDP in a
> 488 response, at least not within next 20 years.

Again I presume you are right regarding *current* status.
But if it were to become known that doing so is beneficial to completing 
calls successfully, then it doesn't seem at all difficult to do.

For instance, if this were to be seen as a way to achieve better interop 
as IPv6 is deployed, people might be motivated to do it.
It might be easier that using ICE. OTOH, there are other reasons to use 
ICE, and it is probably a better solution.

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

Re: [Sip-implementors] Query on Subscription dialog for reg event upon DeRegistration

[Paul Kyzivat]

Sunil,

Its not clear to me if you have a question for sip-implementors, or a 
question for IMS-implementors.

The reg event package provides a way to monitor the status of *all* the 
registrations for a particular AoR. The fact that a UA has unregistered 
itself (or been unregistered) does not mean it has no interest in other 
registrations. If indeed it has no further interest it is certainly free 
to terminate its subscription. But it is the one that can determine the 
continued need, not the registrar.

For instance, I can certainly imagine a "backup" UA that monitors 
registrations on an AoR, and only registers itself if it sees that there 
are no other registrations.

And from a practical perspective, a subscription to the reg event 
package is the way a UA can learn that it has been unregistered and 
might want to try registering again. If the subscription is terminated 
at the time the registrar terminates the registration, then the 
notification of unregistration can't be sent.

Thanks,
Paul

On 1/13/2011 7:24 AM, Sunil wrote:
> Hi All,
>
> According to the  3GPP  24.229 spec,
>
>   Upon successful de-registration UA should not delete the dialog for
> Subscription to reg event package if it had subscribed.
>
>
> Exerts from 24.229:
> 
> Prior to sending a REGISTER request for deregistration, the UE
> shall release all dialogs related to the public user identity that is
> going to be deregistered or to one of the implicitly registered public
> user identities.
>
> However:
> -   if the dialog that was established by the UE subscribing
> to the reg event package used the public user identity that is going to
> be deregistered ; and
> -   this dialog is the only remaining dialog used for
> subscription to reg event package;then the UE shall not
> release this dialog.
> -
>
> What is the use of keeping this dialog when registration itself is
> removed as Subscription to reg event package tells about the
> registration status.Upon successful de-registration UA knows that its
> registration status for that user is terminated.So is it not right to
> delete the Subscription to reg event package on deregistration ?
>
> Also from the same spec,it tells that if signaling security is
> involved(IPsec/tls),on deregistration security associations will be
> deleted and further messages can not be received. So if UA does keep the
> dialog
> even after deregistration and the server tries to send NOTIFY WITH
> TERMINATED STATE ,it won't reach the UA as already security associations
> are deleted.
> -
>   When the UE has received the 200 (OK) response for the REGISTER
> request of the only public user identity currently registered with its
> associated set of implicitly registered public user identities (i.e. no
> other is registered), the UE removes the security association
> established between the P-CSCF and the UE. Therefore further SIP
> signalling (e.g. the NOTIFY request containing the deregistration
> event)
> will not reach the UE.
> ---
>
> So it makes sense to delete the Subscription to reg event package on
> deregistration without waiting for NOTIFY WITH TERMINATED STATE .
>
>
> Please opine.
>
>
> Regards,
> Sunil
>
>
> ___
> 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] draft sipping-v6-transition and SDP offer/answer

[Paul Kyzivat]

Also, the following from the description of 488:

A message body containing a description of media capabilities MAY be
present in the response, which is formatted according to the Accept
header field in the INVITE (or application/sdp if not present), the
same as a message body in a 200 (OK) response to an OPTIONS request.

could be used to indicate support, say for ipv6 and not ipv4. Then the 
offerer could analyze that (if I received such an offer, what would I 
answer) and if it comes up with something workable it can then send a 
new invite with that as the offer.

Thanks,
Paul

On 1/11/2011 6:58 AM, Olle E. Johansson wrote:
>
> 11 jan 2011 kl. 11.20 skrev Saúl Ibarra Corretgé:
>
>>> I thought of that - but what would we put there that everyone could support?
>>>
>>
>> For the codec related 488, a 305 "Incompatible media format" could be
>> used. For IPv4/IPv6 stuff, 300 "Incompatible network protocol" or 301
>> "Incompatible network address formats" could help.
>>
>> If none of them suit the needs, maybe a new draft needs to be written
>> extending the warning codes with some new ones addressing these new
>> needs :-)
>>
>> My 2 cents,
>
> Those cents had very high value to me. I have been blind - that's exactly
> what we need. Perfect!
>
> Thanks, Saghul!
>
> /O
> ___
> 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 early media sessions within a samedialog

[Paul Kyzivat]

You are right that in theory the announcement can be sent without 
sending an answer. But in practice its often impossible to get media 
received without sending an answer first. Either the UAC will restrict, 
or in some cases an SP will gate media based on the answer.

Thanks,
Paul

On 1/8/2011 9:08 AM, Kevin P. Fleming wrote:
> On 01/07/2011 09:47 PM, Paul Kyzivat wrote:
>>
>>
>> On 1/7/2011 9:21 PM, SIP Satan wrote:
>>> Cant we play multiple announcements by giving different SDP's  in
>>> multiple 1xx responses provided
>>> each 1xx carries a different To-tag. In a way simulating forking
>>> environment.
>>
>> Yeah, should be fine. To the other end its indistinguishable from "real"
>> forking.
>>
>> That of course assumes that the UAC is capable of rendering media from
>> different early dialogs.
>
> Maybe I'm missing something obvious (it is Saturday morning after all),
> but why does the UAS need to send an SDP *at all* in order to play
> announcements? If the UAC included an SDP offer in the initial INVITE,
> then it is prepared to receive media on any sessions in that offer that
> are either 'active' or 'recvonly', whether it receives an answer or not.
> If the UAC did not include an SDP offer in the initial INVITE, then
> announcements can't be played until the UAS sends a 200 OK (with SDP)
> and receives an ACK (with SDP).
>
> Since announcements are typically unidirectional media (the announcement
> server doesn't need to receive media from the caller, and would just
> throw it away if it did), then the media can be sent to the caller
> without doing anything more than sending a single '183 Session
> Progress', and it does not even need to include an SDP answer.
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Multiple early media sessions within a samedialog

[Paul Kyzivat]

On 1/7/2011 9:21 PM, SIP Satan wrote:
> Cant we play multiple announcements by giving different SDP's  in
> multiple 1xx responses provided
> each 1xx carries a different To-tag. In a way simulating forking
> environment.

Yeah, should be fine. To the other end its indistinguishable from "real" 
forking.

That of course assumes that the UAC is capable of rendering media from 
different early dialogs.

Thanks,
Paul

> Regards
> -Satan
>
> On Fri, Jan 7, 2011 at 8:42 PM, Paul Kyzivat  <mailto:pkyzi...@cisco.com>> wrote:
>
> inline
>
> On 1/7/2011 12:10 AM, Parthasarathi R (partr) wrote:
>  > Hi,
>  >
>  > Please read inline
>  >
>  > Thanks
>  > Partha
>  >
>  > -Original Message-
>  > From: sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu>
>  > [mailto:sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu>] On Behalf Of
>  > Nataraju A.B
>  > Sent: Thursday, January 06, 2011 10:40 PM
>  > To: Harlin Dyvia Helina Sathianathan
>  > Cc: sip-implementors@lists.cs.columbia.edu
> <mailto:sip-implementors@lists.cs.columbia.edu>
>  > Subject: Re: [Sip-implementors] Multiple early media sessions
> within a
>  > samedialog
>  >
>  > After the first 1xx, it is not allowed to send UPDATE with a
> different
>  > SDP for announcement-2.
>
> That is only true when PRACK is not used.
>
> Once the answer has been sent in a *reliable* response, then another O/A
> exchange can occur within the same dialog.
>
>  > I think offer-answer model discussed some set of
>  > cross over scenarios in detail. If I am not wrong this is the
> scenario
>  > you are looking for ?
>  >
>  > INV -->
>  > <-- 1xx(SDP)
>  > -->  PRACK
>  > <-- 200-PRACK
>  >
>  > <-- UPDATE(Callee)
>  > 200-UPDATE -->
>  >
>  > <-- UPDATE(Callee)
>  > 200-UPDATE -->
>  >
>  > <-- 200-INVITE
>  > ACK -->
>
> Yes, I presume that is what the question is about.
> That should be fine.
>
> Of course it won't work if the caller hasn't indicated support for
> 100rel and you want to send these announcements.
>
> The alternative is to treat the call as being forked serially to each
> announcement server and then to the final recipient. Each then
> establishes its own early dialog and plays its message. In that case it
> is up to the UAC to deal with and hopefully play the media from each
> early dialog. While that is a challenge if they occur in parallel, it
> should not be such a challenge if they occur serially. There is however
> no indication that these early dialogs are terminating before the next
> one starts. (But see the draft on 199.)
>
> Thanks,
> Paul
>
>  > It was intentionally restricted to allow only one SDP negotiation
> during
>  > session setup. Once the call is setup, you can have as many
>  > re-negotiations as possible. This makes offer-answer handling UA's
>  > simpler...
>  >   I really don't know whether any such restriction exists
> in the
>  > offer/answer draft. If so, it has to be revisited as multiple
>  > announcement is common scenario in the network.
>  >
>  > I suggest some more detailed study on offer-answer model draft is
>  > required.
>  > You are suggested to go through earlier discussion on
> offer-answer draft
>  > as well.
>  >
>  > Hope this helps
>  >
>  > On Wed, Jan 5, 2011 at 10:17 AM, Harlin Dyvia Helina Sathianathan<
>  > harlin.sathianat...@aricent.com
> <mailto:harlin.sathianat...@aricent.com>>  wrote:
>  >
>  >>   Hi Nataraju,
>  >>
>  >>
>  >>
>  >> Thanks for your inputs.
>  >>
>  >> Sending different SDPs in multiple 1xx messages might be
> violating the
>  >
>  >> offer-answer model,
>  >>
>  >> but if the first announcement is through reliable-1xx response
> and the
>  >
>  >> subsequent announcement is with UPDATE, then I guess it should be
>  >> technically right.
>  >   This may break

Re: [Sip-implementors] Multiple early media sessions within a samedialog

[Paul Kyzivat]

inline

On 1/7/2011 12:10 AM, Parthasarathi R (partr) wrote:
> Hi,
>
> Please read inline
>
> Thanks
> Partha
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Nataraju A.B
> Sent: Thursday, January 06, 2011 10:40 PM
> To: Harlin Dyvia Helina Sathianathan
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Multiple early media sessions within a
> samedialog
>
> After the first 1xx, it is not allowed to send UPDATE with a different
> SDP for announcement-2.

That is only true when PRACK is not used.

Once the answer has been sent in a *reliable* response, then another O/A 
exchange can occur within the same dialog.

> I think offer-answer model discussed some set of
> cross over scenarios in detail. If I am not wrong this is the scenario
> you are looking for ?
>
> INV -->
> <-- 1xx(SDP)
> -->  PRACK
> <-- 200-PRACK
>
> <-- UPDATE(Callee)
> 200-UPDATE -->
>
> <-- UPDATE(Callee)
> 200-UPDATE -->
>
> <-- 200-INVITE
> ACK -->

Yes, I presume that is what the question is about.
That should be fine.

Of course it won't work if the caller hasn't indicated support for 
100rel and you want to send these announcements.

The alternative is to treat the call as being forked serially to each 
announcement server and then to the final recipient. Each then 
establishes its own early dialog and plays its message. In that case it 
is up to the UAC to deal with and hopefully play the media from each 
early dialog. While that is a challenge if they occur in parallel, it 
should not be such a challenge if they occur serially. There is however 
no indication that these early dialogs are terminating before the next 
one starts. (But see the draft on 199.)

Thanks,
Paul

> It was intentionally restricted to allow only one SDP negotiation during
> session setup. Once the call is setup, you can have as many
> re-negotiations as possible. This makes offer-answer handling UA's
> simpler...
>   I really don't know whether any such restriction exists in the
> offer/answer draft. If so, it has to be revisited as multiple
> announcement is common scenario in the network.
>
> I suggest some more detailed study on offer-answer model draft is
> required.
> You are suggested to go through earlier discussion on offer-answer draft
> as well.
>
> Hope this helps
>
> On Wed, Jan 5, 2011 at 10:17 AM, Harlin Dyvia Helina Sathianathan<
> harlin.sathianat...@aricent.com>  wrote:
>
>>   Hi Nataraju,
>>
>>
>>
>> Thanks for your inputs.
>>
>> Sending different SDPs in multiple 1xx messages might be violating the
>
>> offer-answer model,
>>
>> but if the first announcement is through reliable-1xx response and the
>
>> subsequent announcement is with UPDATE, then I guess it should be
>> technically right.
>   This may break few callflow wherein 18x is expected to play the
> announcement or change the announcement. UPDATE updates media part (SDP)
> but not indicates which types of announcement.  Multiple 18x may needed
> but it depends upon the device which you interop
>>
>> Correct me if I am wrong.
>>
>>
>>
>> Regards,
>>
>> Harlin
>>
>>
>>   --
>>
>> *From:* Nataraju A.B [mailto:nataraju@gmail.com]
>> *Sent:* Tuesday, January 04, 2011 6:36 PM
>> *To:* Vivek Talwar
>> *Cc:* Harlin Dyvia Helina Sathianathan; $...@r\/|>r!`/@; Worley, Dale R
>> (Dale); sip-implementors@lists.cs.columbia.edu
>>
>> *Subject:* Re: [Sip-implementors] Multiple early media sessions within
>
>> a same dialog
>>
>>
>>
>> Hi All,
>>
>>
>>
>> with in the same session, playing announcements is not allowed. There
>> could be only on dialog established between UAC and UAS1(to_tag1). But
>
>> there could be multiple dialogs established @ UAC due to UAS1, UAS2,
>>  but not by the same UAS. Sending diferent SDPs in multiple 1xx
>> messages would violate offer-answer model.  if multiple dialogs were
>> created in UAC / Proxy, care must be taken while passing the responses
>
>> back to User_Application/UAC
>>
>>
>>
>> you can refer *
>> http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13* for
>> more details.
>>
>>
>>
>> Thanks,
>>
>> Nataraju A.B.
>>
>>
>>
>>
>>
>> On Tue, Jan 4, 2011 at 11:48 AM, Vivek Talwar
>> 
>> wrote:
>>
>> Hi Harlin,
>>   I think you want to play two sequential early media announcements
>
>> back to back. This can be achieved  with same tag but the server
>> involved in SIP signaling for initiating early dialog have to take
> care of this.
>>
>> Thanks and Regards,
>> Vivek Talwar
>> 
>> From: sip-implementors-boun...@lists.cs.columbia.edu [
>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Harlin
>> Dyvia Helina Sathianathan
>> Sent: Tuesday, January 04, 2011 11:34 AM
>> To: $...@r\/|>r!`/@; Worley, Dale R (Dale)
>> Cc: sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Multiple 

Re: [Sip-implementors] What is the use of port number in SIP-URI in FROM header?

[Paul Kyzivat]

IMO, if a UA is given a URI to call, it generally has no business 
messing with it in any way. Removing the port is altering the URI, and 
should only be done by something in the domain of the URI that is 
familiar with the policies for construction of URIs within that domain.

If the UA is *constructing* the URI, based on some policy rules known to 
it for such construction, then it can construct one URI with the port 
(for the R-URI) and one without (for the to-uri.)

Messing with URIs from other domains is like modifying a postal address 
for a recipient in a foreign country. You likely don't know the 
conventions for formatting postal addresses in that place and have a 
good chance of rendering your mail undeliverable.

Thanks,
Paul

On 1/4/2011 10:39 AM, Iñaki Baz Castillo wrote:
> 2011/1/4 Brett Tate:
>> I'm not sure how the SIP working group intended RFC 3261 section 19.1 Table 
>> 1 paragraph indicating "SHOULD ignore any disallowed components" to apply to 
>> section 19.1.4's URI comparison rules.
>
> Fuly unclear. We could give our opinnion here, and any other person
> could have his own opinnion :)
>
>
>> However it might be problematic if you drop received To/From ports when 
>> sending requests within dialog.
>
> IMHO it's much better just to ignore port in From/To URI when comparing URI's.
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] SIP Call/Hold Scenario

[Paul Kyzivat]

Look at the offeranswer draft for a discussion of this.
While your option 1 will "work" in some cases, it won't always work. 
Specifically, if both sides put the call on hold, then there will be no 
way to get off hold.

The solution is to always offer the directionality your end wants, 
without regard to what you think the other end wants. The other end can 
take care of its needs in the answer.

Thanks,
Paul

On 1/4/2011 8:23 AM, Nataraju A.B wrote:
> We should proceed with option-1. In this case Re-Invite with out SDP leads
> to delayed media negotiation...
>
> On Tue, Jan 4, 2011 at 6:36 PM, Chandan Kumarwrote:
>
>> Hi ,
>>
>> Thanks  for the responses. Even I thougt the same.
>>
>> Lets say for the same case mean  for unholding the call , if we get
>> Re-inivte with no SDp from B2BuA . How SIP entity should respond ( SIP
>> entity is in Held state).
>>
>> Does SIP entity should respond with the Current state with 200 ok putting
>> media attribute as a=Inactive
>>
>> (or)
>>
>> For  Reinvite regardless of the state we need to  respond in 200 Ok with
>> media a=sendrecv?
>>
>> This is issue faced by on of our customers. Our software always respond
>> with curretn state for Re-Invite Message.
>>
>> But for the same case the X-lite Phone responds with a=sendrecv ?
>>
>>
>> How to deal with this issue&  which is correct option .
>>
>>
>> Best Regards,
>> Chandan.
>>
>> --- On Tue, 4/1/11, Harlin Dyvia Helina Sathianathan<
>> harlin.sathianat...@aricent.com>  wrote:
>>
>>
>> From: Harlin Dyvia Helina Sathianathan
>> Subject: RE: [Sip-implementors] SIP Call/Hold Scenario
>> To: "Chandan Kumar", "
>> sip-implementors@lists.cs.columbia.edu"<
>> sip-implementors@lists.cs.columbia.edu>
>> Date: Tuesday, 4 January, 2011, 6:18 AM
>>
>>
>> Hi,
>>
>> The call hold scenario looks working right but the entity in between A and
>> B should be a B2BUA. Thus B2B sends back SDP-answer with c = 0.0.0.0&  a =
>> Inactive behalf of B in case of call hold, which is right.
>>
>> But in the call unhold scenario,B2B should have sent an offer to B with
>> a=sendrecv. This should be a bug with B2B.
>>
>> Regards,
>> Harlin
>>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Chandan Kumar
>> Sent: Monday, January 03, 2011 4:11 PM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: [Sip-implementors] SIP Call/Hold Scenario
>>
>> Hi All ,
>>
>> This is an query regarding call hold scenario .
>> Two  phones A,B  are registered to SIP proxy. Let's say A&  B are in call.
>>
>> 1.Now A  holds  the call by changing medi attribute in SDP to  a= sendonly.
>> 2.Proxy sends signalling message Trying.
>> 3..Proxy sends 200 OK with SDP to Phone A in which media attribute set to
>> c = 0.0.0.0&  a = Inactive
>> My Question is the proxy is sending 200 ok to  Phone A by changing media
>> attibute.Is this correct?
>>
>> As far as my understanding Proxy should send the invite message to other
>> endpoint i.e B.
>>
>> 4.Apart from above issue ,later on proxy sends Invite  with c=0.0.0.0&
>> a=Inacitve  to B.
>> As usual B responds with Inacitve.
>>
>> Till here call is on Hold.
>>
>> Unhold scenario: Now call between A&  B is held.
>>
>> 1.A unholds the call ,changing media attribute to a = sendrecv.
>> 2.But the proxy again changing the media attribute to a=inactive&
>> connection Ip c=0.0.0.0 sends the Invite message to Phone B.
>>
>> Why the proxy is behaving strangly? Is this a bug with proxy.
>>
>> 3.Phone responds with medai attribute a= Inactive.
>>
>> Because of these reasongs call hold/unhold is failing.
>>
>> Please let me know whether proxy behaviour is correct ot not?
>>
>> Accoring to RFC my understading is :
>> sendrecv - Used to establish a 2-way media stream.
>> recvonly - The SIP endpoint would only receive (listen mode) and not send
>> media.
>> sendonly - The SIP endpoint would only send and not receive media.
>> inactive -  The SIP endpoint would neither send nor receive media.
>>
>>
>>
>>
>> Best Regards,
>> Chandan.
>>
>>
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
>> for the use of the individual to whom it is addressed. It may contain
>> privileged or confidential information and should not be circulated or used
>> for any purpose other than for what it is intended. If you have received
>> this message in error, please notify the originator immediately. If you are
>> not the intended recipient, you are notified that you are strictly
>> prohibited from using, copying, altering, or disclosing the contents of this
>> message. Aricent accepts no responsibility for loss or damage arising from
>> the use of the information transmitted by this email including damage from
>> vir

Re: [Sip-implementors] In-dialog (?) request ignoring route set

[Paul Kyzivat]

Its not really a responsibility of the recipient to check this, at least 
in straightforward cases. How would it know that the proxy has been 
bypassed? If the request arrives, and has the correct form, then I would 
expect the UAS to process the request. To detect the problem it would 
have to notice that the Via isn't consistent with the route set. But 
that isn't so easy to determine.

But its still incorrect behavior, whether detected or not. Typically 
*something* won't work.

Thanks,
Paul

On 1/4/2011 10:58 AM, Worley, Dale R (Dale) wrote:
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Olle E. 
> Johansson [...@edvina.net]
>
> Now one UA sends a SIP request directly between the UA's instead of following 
> the route set for the dialog.
>
> - Should this request be dropped?
> - Should it be accepted and processed?
> - Shout it be responded to with an error message - if so, which one do you 
> suggest?
> ___
>
> I suppose the best choice is to process it and return the response based on 
> the Via's.  But it doesn't really matter, since the request clearly should 
> not have been generated.
>
> I am surprised that any UA performs the checks necessary to determine that 
> this has happened.  But if it discovers the problem, it should log it 
> somewhere for human interpretation.
>
> 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] re-INVITE and inactive

[Paul Kyzivat]

I gather that UAS is actually a B2BUA.
Does it also terminate and relay media?
Or does it simply forward media descriptions from one leg to the other?
(I suspect from your description that it terminates and relays media.)

As long as it is functioning as a B2BUA, there is nothing obviously 
wrong *technically* with what it has done. Its free to manage the two 
dialogs independently as it wishes.

As long as it terminates the video stream from UAS1, and doesn't forward 
the video while UAS2 has video set to inactive, it is also working in a 
defensible way, though perhaps not the most obvious way.

This is probably an area where the application is just not working the 
way you would wish, but the issues are not related to standards.

Thanks,
Paul

On 12/6/2010 7:08 AM, alex.north.e...@gmail.com wrote:
> Hi All!
>
> My question about a=inactive attribute of SDP and re-INVITE.
> We  have  implemented  re-INVITE for our UAC. Our re-INVITE changes media 
> session and add video
> codecs to SDP and it works and tested with some sip proxies.
>
> But with Asterisk and Bria, we have strange behavior:
> Assume, that Asterisk is UAS and Bria is UAC1, UAC2
>
> 1. UAC1 INVITE to UAS with audio codecs only in SDP, audio a=sendrecv
>
> 2.  UAS  INVITE  to  UAC2  with  audio  and video codecs in SDP, audio
> a=sendrecv, video a=sendrecv
>
> 3.  UAC2  200  OK  to  UAS  with  audio and video codecs in SDP, audio
> a=sendrecv, video a=inactive
>
> 4.  UAC1  re-INVITE  to  UAS  with  audio  codecs  and  video  codecs,
> a=sendrecv, video a=sendrecv
>
> 5. UAS 200 OK to UAC1 with  audio  codecs  and  video  codecs,
> a=sendrecv, video a=sendrecv
>
> 6. ACKs...
>
> Then RTP audio+video conversation has been established.
>
> But in this scenario, UAS does not transmit re-INVITE to UAC2 at all.
> Is it rfc3261 violation?
>
> UAC2 starts send  RTP video packets after packets received
> from UAS.
>
> Is  it  correct  implementation  or workaround? - to start sending RTP
> packets after receiving packets from the far end? If it is not workaround.
> What specification describes 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] Dropping calls by SIP stateful proxy

[Paul Kyzivat]

There is nothing to prevent a proxy from being "dialog aware" / "dialog 
stateful". If it wants to be dialog stateful it needs to Record-Route so 
that it is privy to mid-dialog signaling.

But there are limits to what is possible with a proxy that is conformant 
to 3261. In particular, the proxy cannot initiate new requests (e.g. 
BYE) in the dialog. So it is dependent on the UAs to initiate requests.

If you need to initiate requests within the dialog then the only valid 
way to do so is to be a UA. If you want to be "proxy-like' in this case 
then you will be a B2BUA. Such a thing is typically called an SBC.

Thanks,
Paul

On 12/3/2010 6:29 AM, Iñaki Baz Castillo wrote:
> 2010/12/3 Vadim Lebedev:
>>
>> I wonder what is the best strategy to adopt in folowing scenarios:
>>
>> 1. Endpoint A sends INVITE to B through stateful proxy P
>> 2. B responds with 100 then with 180 which are succesuflly deliverd to A
>> 3.1 B sends 200
>> 3.2 P decides that it needs to drop the call   (Because of dread media
>> gateway detection for example)
>>What would be the best strategy for P?
>>It seems that it can send 6xx to A but what it is supposed to
>> send to B?  a BYE?
>
> A proxy, by definition, cannot act in this case.
>
>
>
>> The second scenario is:
>> 1. Endpoint A sends INVITE to B through stateful proxy P
>> 2. B responds with 100 then with 180 which are succesuflly deliverd to A
>> 3 B sends 200 which is delivered to A
>> 4.  P decides that it needs to drop the call.
>>What would be the best strategy for P in this case?
>
> Again a proxy (transaction stateful proxy) is not dialog aware so it's
> not capable of terminating a dialog (it doesn't know about current
> dialogs).
>
> However some proxies are "dialog" aware (just limitations) and can
> generate a BYE for each participant in the dialog (your second case).
> For the first case there is no way in a proxy.
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] dynamic payload negotiation

[Paul Kyzivat]

We rarely revise RFCs solely to clarify the wording. Sometimes we issue 
clarifying RFCs instead. Or the clarification is simply captured as an 
errata and then it will be incorporated if/when the RFC is revised.

Thanks,
Paul

On 11/29/2010 11:20 AM, Iñaki Baz Castillo wrote:
> 2010/11/29 Schwarz, Albrecht (Albrecht):
>> Asymmetric media configurations are in general possible.
>> See SDP Offer/Answer, RFC 3264.
>> Both directions are independent.
>> Thus, different media configurations may be negotiated for the two 
>> Offerer-to-Answerer directions.
>
>
>
>> To the folks responsible for these RFCs:
>> this is a FAQ since years and years, it would be really beneficial to make 
>> such conceptual things more explicit in the RFC texts.
>
> I strongly agree.
>
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] CENTREX Solution with SIP

[Paul Kyzivat]

On 11/29/2010 11:06 AM, Alex Balashov wrote:
> On 11/29/2010 10:44 AM, Ali Kemal MAYUK wrote:
>
>> I am investigating about how Centrex work with SIP. If an enterprise
>> customer has a 2 different locations, how they call each other with short
>> numbers(4 digit) ? Which SIP headers are used for it? Is there a
>> standartization ? Does any one have a solution documentation? How the big
>> companies handle it?
>
> This is not a question about SIP protocol mechanics or implementation,
> although you may not know that.
>
> Your question is about an abstraction of SIP endpoint behaviour
> (initiating calls between two or more endpoints) to serve the needs of a
> high-level application and/or marketable product.  There is nothing
> special whatsoever about how "Centrex"-like products are implemented
> using SIP endpoints, nor any specific accommodation for this kind of
> functionality within the protocol.
>
> Your real question is, "How do I dial between SIP endpoints using
> arbitrary routing designations?"

good restatement

> The answer is:  the same way you'd
> dial in any other scenario.  As usual, the dialed digits are present in
> the Request URI and (usually) the To header.

There are at least two answers (probably more):

- as you state, R-URI contains dialed digits. Some server acting on 
behalf of caller translates this into a more complete one - e.g. E.164 
format - and then routes appropriately.

- the calling phone may be provisioned with enough of the dial plan so 
that *it* can expand the dialed digits into a complete URI for the 
called party, then sends the INVITE.

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 gruu

[Paul Kyzivat]

On 11/27/2010 1:33 AM, SIP Satan wrote:
> 1. what is the usage of expires parameter in Contact header ? How this
> parameter is different from Expires header field ?
> ANS>>   Expires in contact header serves the same purpose as in expires
> header(make sense when there are multiple contacts in single REGISTER).
> 2. In case of re-registration, temp-gruu generated by registrar will be
> different from previous one?
> ANS>>  Life time of a temp gruu is till life time of the registration, any
> new/no temp-gruu in re-registration 200OK invalidates the first.

The reregistration assigns a new temp gruu, but it doesn't invalidate 
the first one. The temp gruus only become invalid with the registration 
fails to be refreshed.

Thanks,
Paul

> On Sat, Nov 27, 2010 at 11:47 AM, meena singla> wrote:
>
>>
>>
>> Hello,
>>
>> pls clarify my doubts wrt GRUU
>> 1. what is the usage of expires parameter in Contact header ? How this
>> parameter is different from Expires header field ?
>>
>> 2. In case of re-registration, temp-gruu generated by registrar will be
>> different from previous one??
>>
>>
>> --
>>
>>
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> Meena Singla
>>
>>
>>
>> Email: meena.sin...@rancoretech.com
>>
>>
>>
>> ___
>> 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 regarding SDP attribute in a Call Hold Resume Scenario

[Paul Kyzivat]

On 11/25/2010 6:15 AM, Tarun2 Gupta wrote:
> Hi All
>
> Consider the following scenario:
>
>
>   1.  Call connected between A and B.
>   2.  A holds the call with a=sendonly.
>   3.  B sends 200 ok with a=recvonly.
>   4.  B again holds the call with a=inactive.
>   5.  What should A send in 200 ok response (a=sendonly or a=inactive) ??

Inactive

>   6.  B resumes the call with a=recvonly.

While that will work in most cases, it would be preferable for B to 
resume the call with a=sendrecv. (This is assuming that B is ready and 
able to send as well as receive.

>   7.  A sends 200 ok with a=sendonly.

If A still desires the call to be on hold, then A will indeed answer 
with sendonly, whether the offer had been recvonly or sendrecv.

>   8.  A again resumes the call with a=sendrecv.
>   9.  What should B send in 200 ok response (a=recvonly or a=sendrecv) ??

I think we have established that B no longer wishes the call to be on 
hold, so it should indeed answer with sendrecv.

There is a more complete explanation of this in 
http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-13.txt.

Thanks,
Paul

> Regards,
> Tarun Gupta
> Aricent
>
>
> 
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely 
> for the use of the individual to whom it is addressed. It may contain 
> privileged or confidential information and should not be circulated or used 
> for any purpose other than for what it is intended. If you have received this 
> message in error, please notify the originator immediately. If you are not 
> the intended recipient, you are notified that you are strictly prohibited 
> from using, copying, altering, or disclosing the contents of this message. 
> Aricent accepts no responsibility for loss or damage arising from the use of 
> the information transmitted by this email including damage from virus."
> ___
> 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 regarding SDP answer in reliable 18x with inactive stream only

[Paul Kyzivat]

On 11/19/2010 7:04 PM, Wyne Wolf wrote:
> A lot of VoIP based pbxes does not send a 200 during the greeting. They send
> a 183 with early media instead. They will continue with the ivr script until
> a dtmf input is expected, then the send a 200.

Yup. And its my understanding that some SPs only allow the early media 
from servers they control - blocking it from those they don't control.

In any case that is only one reason the UAS might want to start the call 
out in inactive mode. There are other reasons. If the UAC makes 
assumptions about this it may produce less than acceptable results.

Thanks,
Paul

> On Fri, Nov 19, 2010 at 6:33 PM, Paul Kyzivat  wrote:
>
>> I agree with Dale, with an added comment
>>
>> On 11/19/2010 5:04 PM, Worley, Dale R (Dale) wrote:
>>> 
>>> From: sip-implementors-boun...@lists.cs.columbia.edu [
>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Tarun2 Gupta
>> [tarun2.gu...@aricent.com]
>>>
>>> Consider the following scenario:
>>>
>>>1.  A sends INVITE to B with SDP 1 as offer.
>>>2.  B sends reliable 183 with answer having 1 inactive stream only
>> (with a=inactive)
>>>
>>> Now my question is that
>>>
>>>1.  Is B's behavior correct (with respect to reliable/non-reliable 18x)
>> ? Can you give me some reference (RFC/draft) in support of your answer ?
>>>2.  In my case, A is sending PRACK followed by CANCEL. Is this correct?
>>
>> Its not *incorrect* - you are free to cancel if you wish, for whatever
>> reason you wish. So if you don't wish to establish a call with the media
>> in inactive state you may do this.
>>
>> BUT its probably a bad idea, because you may be blocking communication
>> when your user would wish you had not. There are a variety of reasons
>> why the UAS might do this. For instance, some service providers may
>> cause this behavior because they don't want to exchange media until the
>> 200 because that is when they can start billing for it.
>>
>> I think it would probably be better to allow the call to continue and
>> let the user decide. But in the end it is an implementation choice.
>>
>> Paul
>>
>>> 
>>>
>>> Both of these are correct because no specification forbids them.  In
>> particular, an offered m= line with a=sendrecv may be answered with
>> a=inactive per the SDP offer/answer specifications.
>>>
>>> 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
>>
> ___
> 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 regarding SDP answer in reliable 18x with inactive stream only

[Paul Kyzivat]

I agree with Dale, with an added comment

On 11/19/2010 5:04 PM, Worley, Dale R (Dale) wrote:
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Tarun2 Gupta 
> [tarun2.gu...@aricent.com]
>
> Consider the following scenario:
>
>   1.  A sends INVITE to B with SDP 1 as offer.
>   2.  B sends reliable 183 with answer having 1 inactive stream only (with 
> a=inactive)
>
> Now my question is that
>
>   1.  Is B's behavior correct (with respect to reliable/non-reliable 18x) ? 
> Can you give me some reference (RFC/draft) in support of your answer ?
>   2.  In my case, A is sending PRACK followed by CANCEL. Is this correct?

Its not *incorrect* - you are free to cancel if you wish, for whatever 
reason you wish. So if you don't wish to establish a call with the media 
in inactive state you may do this.

BUT its probably a bad idea, because you may be blocking communication 
when your user would wish you had not. There are a variety of reasons 
why the UAS might do this. For instance, some service providers may 
cause this behavior because they don't want to exchange media until the 
200 because that is when they can start billing for it.

I think it would probably be better to allow the call to continue and 
let the user decide. But in the end it is an implementation choice.

Paul

> 
>
> Both of these are correct because no specification forbids them.  In 
> particular, an offered m= line with a=sendrecv may be answered with 
> a=inactive per the SDP offer/answer specifications.
>
> 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] ACK cannot stop the flood of 200 OK from sipgate.com

[Paul Kyzivat]

It would seem that your ACK isn't being recognized as matching the 
INVITE. Without details can't say if the fault is with the UAC or UAS.

What's needed to sort it out is the INVITE, 200, and ACK messages.

Thanks,
Paul

On 11/19/2010 4:16 PM, Wyne Wolf wrote:
> Hi all,
>
> I am new here. We have done a sip implementation and are testing it against
> many sip servers and services out there. It works good except when we are
> testing against a VoIP provider sipgate.com. When we send an inviter, the
> call proceeds and eventually their server returns a 200 OK, we immediately
> ACK it. However, their server continues to send 200 OKs for the original
> invite for about 20 seconds and than they terminate the call. During the
> entire 20 seconds, we have audio going on both directions. We have compare
> our sip trace with the one from xlite (xlite works), but we have no idea at
> this point what is going on. Their server seems to 'lost' or 'ignored' our
> ACK send for the 200 OK. Any one encounter this problem before with them?
> Thnx.
>
> I can provide a wireshark trace if it is helpful. Just don't want to waste
> bandwidth here.
> ___
> 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 gruu

[Paul Kyzivat]

On 11/11/2010 2:19 PM, meena singla wrote:
>
>
> Hello,
>
> As P-CSCF does not maintain any data regarding GRUU during registration. When 
> P-CSCF receives an INVITE request and its Con tact header contains only 
> temp-gruu. How the P-CSCF will process that request?? How P-CSCF will relate 
> that  request to Registration data ?

See the gruu specs. An implementation can construct gruus in such a way 
that no state is required at the registrar.

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 gruu

[Paul Kyzivat]

I don't know one offhand, but I'm quite certain there are some that do.
Hopefully they will speak up.

Paul

On 11/11/2010 1:46 PM, SIP Satan wrote:
> Paul,
>
> Is there any server which supports gruu , along with its reg-event
> package extension ?
>
> Regards
> -Satan
>
> On Thu, Nov 11, 2010 at 11:07 AM, Paul Kyzivat  wrote:
>> The URI you use in the Contact for requests and responses can be
>> anything that works for you. It need not have any relationship to the
>> contact you registered. However, if you receive a request that was
>> addressed to your AOR and routed to you via your registered contact,
>> then the contact you supply in the response ought to be something that
>> is guaranteed to reach your same UA. Some possibilities are:
>> - the URI you supplied as Contact to REGISTER
>> - one of the GRUUs returned by the registrar (if there were some)
>> - the AOR you registered.
>>
>> The URI you registered is the frequent choice. It will usually work for
>> the duration of a dialog established by the initial request to you. But
>> it is often not globally routable, and so it may not work if the other
>> UA uses that address to initiate another out-of-dialog request to you.
>>
>> The GRUUs are intended to solve that problem. If you can get the GRUU
>> then it is probably a better choice. It will help ensure that features
>> like transfer work properly.
>>
>> If you don't have a GRUU, and your contact isn't globally routable, then
>> you can try your AOR. The problem is that in general there is no
>> guarantee that requests sent to it will reach your same UA. There might
>> be other UAs also registered for the same AOR and a request may reach
>> one of them instead. So this is not a good choice in most cases.
>>
>> Good Luck,
>> Paul
>>
>> On 11/11/2010 1:12 PM, meena singla wrote:
>>>
>>>
>>> what about the Sip-URI with which user has registered?
>>>
>>> whether the contact header contains SIP-URI plus gruu or it will contain 
>>> only gruu?
>>> - Original Message -
>>> From: "Iñaki Baz Castillo"
>>> To: "meena singla"
>>> Cc: sip-implementors@lists.cs.columbia.edu
>>> Sent: Wednesday, November 10, 2010 8:05:52 PM GMT +05:30 Chennai, Kolkata, 
>>> Mumbai, New Delhi
>>> Subject: Re: [Sip-implementors] regarding gruu
>>>
>>> 2010/11/10 meena singla:
>>>> 1) what will be the content of contact header?
>>>> 2) contact header field can contain only gruu ?
>>>> 4) contact header can contain temp-gruu only?
>>>
>>> Contact header can contain public and/or private/temp gruu.
>>>
>>>
>>>
>> ___
>> 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 gruu

[Paul Kyzivat]

The URI you use in the Contact for requests and responses can be 
anything that works for you. It need not have any relationship to the 
contact you registered. However, if you receive a request that was 
addressed to your AOR and routed to you via your registered contact, 
then the contact you supply in the response ought to be something that 
is guaranteed to reach your same UA. Some possibilities are:
- the URI you supplied as Contact to REGISTER
- one of the GRUUs returned by the registrar (if there were some)
- the AOR you registered.

The URI you registered is the frequent choice. It will usually work for 
the duration of a dialog established by the initial request to you. But 
it is often not globally routable, and so it may not work if the other 
UA uses that address to initiate another out-of-dialog request to you.

The GRUUs are intended to solve that problem. If you can get the GRUU 
then it is probably a better choice. It will help ensure that features 
like transfer work properly.

If you don't have a GRUU, and your contact isn't globally routable, then 
you can try your AOR. The problem is that in general there is no 
guarantee that requests sent to it will reach your same UA. There might 
be other UAs also registered for the same AOR and a request may reach 
one of them instead. So this is not a good choice in most cases.

Good Luck,
Paul

On 11/11/2010 1:12 PM, meena singla wrote:
>
>
> what about the Sip-URI with which user has registered?
>
> whether the contact header contains SIP-URI plus gruu or it will contain only 
> gruu?
> - Original Message -
> From: "Iñaki Baz Castillo"
> To: "meena singla"
> Cc: sip-implementors@lists.cs.columbia.edu
> Sent: Wednesday, November 10, 2010 8:05:52 PM GMT +05:30 Chennai, Kolkata, 
> Mumbai, New Delhi
> Subject: Re: [Sip-implementors] regarding gruu
>
> 2010/11/10 meena singla:
>> 1) what will be the content of contact header?
>> 2) contact header field can contain only gruu ?
>> 4) contact header can contain temp-gruu only?
>
> Contact header can contain public and/or private/temp gruu.
>
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Restriction on the number of a certain header in a message?

[Paul Kyzivat]

There are a number of headers that may only appear once, including From, 
To, CSeq. IIRC this is addressed in the text relevant to each one.

Thanks,
Paul

On 11/9/2010 1:27 PM, SungWoo Lee wrote:
> Dear,
>
> Does 3261 specify the number of a certain header in a SIP message? We know 
> that multiple Via or Route headers are possible in a message. But what about 
> From header or To header? It obviously sounds weird, but can we put two 
> identical From headers(with same tag) in a single SIP invite request?
>
> Thanks,
>
> Sungwoo
>
> ___
> 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] Identifying Session Refresh UPDATE

[Paul Kyzivat]

An UPDATE is an UPDATE. The effect is strictly a function of its 
content. And as already mentioned, every UPDATE either refreshes the 
session timer, or disables it, regardless of what else it does.

I suppose you might consider that an UPDATE that does nothing else must 
have been intended only to manipulate the session timer. But that is 
mere speculation. There is no way to know (nor *need* to know) why the 
UPDATE was sent.

Best to think of session timer as simply a reminder that you should do 
some additional signaling before it expires.

For instance, if you have a session timer running, and then before it 
expires you have need to do a reINVITE/UPDATE for some *other* reason 
(e.g. hold), then that signaling will reset/cancel the session timer. If 
you have occasion to do that often enough you may never have to 
explicitly refresh your session timer.

Thanks,
Paul

On 11/7/2010 11:02 PM, Priya Arya wrote:
> Hi,
>
> I have one query regarding the Session Refresh UPDATE.
>
> - Just by looking at PDU of UPDATE in a session, can it be idenitified that 
> if this UPDATE is for session refresh or for updating the SDP parameters in 
> the session.
>
> Actually RFC 4028 recommends the following :
> " It is RECOMMENDED that the UPDATE request not contain an offer 
> [4], but a re-INVITE SHOULD contain 
> one, even if the details of the session have not changed."
>
> But if UPDATE is received from UAS containing SDP in it, then can the session 
> version number in the "o-line" be used to identify if this UPDATE is for 
> updating the SDP parameters only.
>
> Thanks in advance.
>
> Regards
> Priya Arya
>
> 
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely 
> for the use of the individual to whom it is addressed. It may contain 
> privileged or confidential information and should not be circulated or used 
> for any purpose other than for what it is intended. If you have received this 
> message in error, please notify the originator immediately. If you are not 
> the intended recipient, you are notified that you are strictly prohibited 
> from using, copying, altering, or disclosing the contents of this message. 
> Aricent accepts no responsibility for loss or damage arising from the use of 
> the information transmitted by this email including damage from virus."
> ___
> 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 Hold

[Paul Kyzivat]

On 11/4/2010 12:24 PM, Nahum Nir wrote:
> Thanks for your advise Paul.
> I'm looking for a "stack" that will only parse the incoming messages and
> build the outgoing massages. The sending, receiving and timers I need to
> implement myself. Can you recommend my about such stack?

Not really - I'm not personally familiar with details of existing public 
stacks. But there are several out there. If you spell out your 
constraints in terms of programming language, OS environment, etc. then 
I'm sure someone will chime in here with suggestions.

If you do your own, you are in for months of work and a lot of time 
debugging your result.

Good luck,
Paul

> Nahum
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul
> Kyzivat
> Sent: Thursday, November 04, 2010 6:11 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Question About Hold
>
> One more thing...
>
> If you are encountering problems like this, it suggests that you are
> building a new sip stack from scratch. If so, you should realize that
> this is not a small task, and it will likely take you a lot of time and
> effort to get it right. You should seriously consider reusing some
> existing stack before committing yourself to building a new one.
>
>   Thanks,
>   Paul
>
> On 11/4/2010 12:01 PM, Worley, Dale R (Dale) wrote:
>> 
>> From: sip-implementors-boun...@lists.cs.columbia.edu
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Nahum Nir
> [hello.shalom...@gmail.com]
>>
>> I checked that RFC and implemented the hold request. I'm testing my stack
>> with x-lite. Upon sending the INVITE that should hold the call I'm
> receiving
>> 482 MERGED REQUEST. What is wrong?
>> ___
>>
>> It is difficult to diagnose SIP problems without a complete trace of the
> dialog.  But it appears that the recipient of the INVITE does not think the
> INVITE is being sent within the dialog that has been already established.
>>
>> 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
>
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Question About Hold

[Paul Kyzivat]

One more thing...

If you are encountering problems like this, it suggests that you are 
building a new sip stack from scratch. If so, you should realize that 
this is not a small task, and it will likely take you a lot of time and 
effort to get it right. You should seriously consider reusing some 
existing stack before committing yourself to building a new one.

Thanks,
Paul

On 11/4/2010 12:01 PM, Worley, Dale R (Dale) wrote:
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Nahum Nir 
> [hello.shalom...@gmail.com]
>
> I checked that RFC and implemented the hold request. I'm testing my stack
> with x-lite. Upon sending the INVITE that should hold the call I'm receiving
> 482 MERGED REQUEST. What is wrong?
> ___
>
> It is difficult to diagnose SIP problems without a complete trace of the 
> dialog.  But it appears that the recipient of the INVITE does not think the 
> INVITE is being sent within the dialog that has been already established.
>
> 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] SDP Offer ANswer

[Paul Kyzivat]

I *think* you have gotten a valid response from other respondents, but 
I'm not certain about the question. You say the terminating party 
supports 100rel, but does the originating party indicate support for 
100rel? That is a necessity to use reliable provisionals.

The thing you want to read is draft-ietf-sipping-sip-offeranswer-13 (not 
-10).

Read that, apply it to your case and come back if you still aren't sure.

Good luck,
Paul

On 11/3/2010 1:48 AM, AGRAWAL, VINEET (VINEET) wrote:
> Hi,
>
> Can any one please clarify, if 100 rel support on the terminating SIP party 
> then the SDP answer of SDP offer received in INVITE  must be in 183 Session 
> progress .
> If I send SDP answer in 180 Ringing in spite of 183. is it ok according to 
> rfc 3264.
> Please clarify the doubts.
>
>
> Regards,
> Vineet
>
> ___
> 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 Response code for codec mismatch

[Paul Kyzivat]

at end

On 10/28/2010 4:23 PM, Worley, Dale R (Dale) wrote:
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of kaiduan xie 
> [kaidu...@yahoo.ca]
>
> Consider the following case, A sends an offer with codec G.729 only, and B 
> does
> not support it, what is the best response code? 415/488 is not for this case
> from rfc3261.
>
> 21.4.13 415 Unsupported Media Type
>
> The server is refusing to service the request because the message
> body of the request is in a format not supported by the server for
> the requested method.  The server MUST return a list of acceptable
> formats using the Accept, Accept-Encoding, or Accept-Language header
> field, depending on the specific problem with the content.  UAC
> processing of this response is described in Section 8.1
>
> 21.4.26 488 Not Acceptable Here
>
> The response has the same meaning as 606 (Not Acceptable), but only
> applies to the specific resource addressed by the Request-URI and the
> request may succeed elsewhere.
>
> A message body containing a description of media capabilities MAY be
> present in the response, which is formatted according to the Accept
> header field in the INVITE (or application/sdp if not present), the
> same as a message body in a 200 (OK) response to an OPTIONS request
>
> And rfc3264 is not clear on this neither,
>
> An offered stream MAY be rejected in the answer, for any reason.  If
> a stream is rejected, the offerer and answerer MUST NOT generate
> media (or RTCP packets) for that stream.  To reject an offered
> stream, the port number in the corresponding stream in the answer
> MUST be set to zero.  Any media formats listed are ignored.  At least
> one MUST be present, as specified by SDP.
> ___
>
> You are correct.  415 is only used when the INVITE's body has a type that the 
> UAS cannot understand.  Since the INVITE's body is always application/sdp, 
> this is never the case.
>
> One alternative is to send a 488 response with a 305 warning code.  (Provide 
> sample SDP showing all codecs the phone supports in the response.)  Another 
> alternative is to send 200 OK but in the SDP reject all the media streams.  
> (But to provide payload numbers for the codecs that the phone does support so 
> that someone trying to diagnose the problem can determine what the phone does 
> support.)

After the 200 response, you could send a reINVITE offering whatever you 
are capable of doing.

But I think the odds of the 200 response and followup doing anything 
useful are slim.

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

Re: [Sip-implementors] basic clarification regarding RFC3680

[Paul Kyzivat]

I suspect as time goes on people are losing the concept of multiple 
devices sharing the same AOR.

Thanks,
Paul

On 10/23/2010 7:38 AM, Iñaki Baz Castillo wrote:
> 2010/10/22 Hazzy:
>> The RFC 3680 states that a single NOTIFY can have details of multiple
>> registrations (AOR)
>
> "registrations" are not "AOR's". If an user (AoR) is registered from N
> devices then it has N registrations (the Contat URI in each REGISTER).
> But it has just *one* AoR.
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] basic clarification regarding RFC3680

[Paul Kyzivat]

The subscription, to an AOR, should give info about registrations for 
that AOR. In principle it can give information about other AORs too.

The only place I know of that uses that is 3gpp/ims. In IMS, a 
subscription to the reg event package for an AOR gives you status on 
that AOR and all "associated" AORs. (E.g. the ones that show up in 
P-Associated-URI.)

Thanks,
Paul

On 10/22/2010 2:04 AM, Hazzy wrote:
> Basically a SUBSCRIBE message To/From header should have a AOR for which the
> user(subscriber) wants to subscribe. Based on this subscription,registrar
> (notifier) will notify about the registration events i.e.
>
> lets say contact/s associated with the subscribed AOR in registrar
> expired,shorten,refreshed,registered etc. Notify will be sent to the 
> subscriber
> with this info. Please confirm if my understanding is correct here.
>
>
> 1.   The RFC 3680 states that a single NOTIFY can have details of multiple
> registrations (AOR). lets say user(subscriber) 'A'  is subscribed for only 1
> AOR. is it possible that he can received Nofity that can have details for
> multiple AOR's ?? If so,what should be the subscriber behavior..it should 
> ignore
> the AOR's for which it hasn't subscriber ?
> Re
>
>Regards,
>Hazzy.
>
>
>
>
> 
> From: "Worley, Dale R (Dale)"
> To: Hazzy; "Sip-implementors@lists.cs.columbia.edu"
> 
> Sent: Wed, 20 October, 2010 7:18:53 PM
> Subject: RE: [Sip-implementors] basic clarification regarding RFC3680
>
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Hazzy
> [hazzy...@yahoo.co.in]
>
> As per RFC3680,UE once registered, it cansubscribe for registration events and
> get the notifications for registrations.
>I need to clarify, how the registration and subscription are associated 
> i.e.
>Lets say User 'A' registers its aor i.e. SIP URI (sip:x...@abcd.com) and
> contact 'X' with the registrar.
> ___
>
> *Any* element can subscribe for the registration events for *any* AOR 
> (provided
> the notifier allows the subscription to be created).
>
> The registration and the subscription are *not associated* with each other
> (other than that the subscription will report the existence of the
> registration).
>
> 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] sdp missing m line

[Paul Kyzivat]

Sorry about that. I remembered the wrong number.

Thanks,
Paul

On 10/1/2010 6:02 PM, Worley, Dale R (Dale) wrote:
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat 
> [pkyzi...@cisco.com]
>
> If so, then it has given the UAS few options.
> The UAS can answer with an SDP containing no m-lines, and thus establish
> a connection with no media.
>
> OR, the UAS can return an error, such as 415, if it doesn't want to
> participate in a call with no media.
>
> I think you will find many/most audio UAs will probably return 415 or
> some other error. It would be more forgiving of them to accept the call
> and just treat it as if on hold for whatever media they have.
> ___
>
>
> Beware that 415 is not the correct error response for this -- 415 means that 
> the UA cannot understand the media type of the body of the INVITE (which will 
> be application/sdp).  Response 488 is used to say that the characteristics of 
> the media described in the SDP body are unacceptable.
>
> 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] why Do we need a 3 way handshake for INVITE at all?

[Paul Kyzivat]

Inline

On 9/22/2010 7:18 AM, abhishek chattopadhyay wrote:
> Hi Implementors,
>
> In 3261 the re-transmission of INVITE is stopped by 1xx responses. So to
> stop the re-trnasmission of 200 OK, ACK is sent.
> (Albait it would be worth considering that ACK is used for a lot of other
> purposes.)
>
> Further form 3261 only, it is clear that for other methods the request would
> be re-transmitted till a 200 is received. The entity sending a 200 OK would
> understand that the 200 has been successfully received if the Method is not
> re-transmitted again.
>
>
> My question is,
> Why at all a 3 way handshake is implimented for INVITE.

INVITE is "special" in that it can take a long time before it is 
answered, due to alerting. There is a desire not to keep retransmitting 
while that goes on. So the retransmits are quenched, and then the ACK is 
required.

The other methods are required to complete quickly, so this process 
isn't used for them.

Another reason is to support INVITEs that don't contain an offer.

Thanks,
Paul

> And
> 100 trying is not restricted for any Method inside a dialog, so if a 100
> Trying is issued for say UPDATE then why it is not the same case as of the
> Re-INVITE's arriving inside the same dialog.
>
>
> Thanks
> 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

Re: [Sip-implementors] Call HOLD from both sides

[Paul Kyzivat]

goutam,

This situation is discussed in section 5.3 of:

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

More inline

On 9/22/2010 5:45 AM, goutam kumar wrote:
> Hi,
>
> I'm trying to implement a VOIP call between two endpoints. I'm in a doubt.
>
> Say Alice and Bob are in a call. Now,
>
> STEP I
> Alice puts Bob on hold.  i.e.
>
>INVITE (RTP-sendonly)
> Alice ->  Bob
>
>200 OK (RTP-recvonly)
>  <
>
>   ACK
>   ->
>
>
> STEP II
> After this Bob puts Alice on hold. i.e.
>
>INVITE(RTP-inactive)
> Alice<--   Bob

It would be better for Bob to offer sendonly here, though inactive is 
also permissible if that is what he really wants.

> 200 OK (RTP-inactive)
>>

If Bob had offered sendonly, then assuming Alice also still wants the 
call held, she would answer inactive as shown.

>   ACK
><
>
> ( If Alice has already put the call on hold, then is Step II possible?? )

Certainly. Why not?

> After this sequence of signaling, say Alice takes the call off hold i.e.
>
>  INVITTE(RTP-sendonly)
> Alice   --->   Bob

You say Alice wants to take the call off hold. So she *wants* sendrecv. 
So she should be offering sendrecv.

>   200 OK (RTP ?)
><

If Alice did offer sendonly, and Bob still wants the call on hold, then 
Bob would have to answer with inactive, since its the only valid answer 
that doesn't have him receiving.

If alice did the better thing of offering sendrecv, then Bob would 
answer with sendonly, which is valid and what he wants.

Thanks,
Paul

> My Question is:What should bob send as a reply now?
> ___
> 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 missing m line

[Paul Kyzivat]

On 9/19/2010 12:38 AM, anand madhab wrote:
> Hi,
>
> No, my query is, I have sent INVITE without m line but with sdp , and i have
> received response 200 ok also with sdp but without m line, so what should
> caller do reject the call or what ? And isn't it like call is on hold
> because there is on media ?
> Or
> Callee should have respond with 415 unsupported media ?

This question is still confusing. IIUC, you are saying that the UAC has 
sent an INVITE with SDP without any m-lines.

If so, then it has given the UAS few options.
The UAS can answer with an SDP containing no m-lines, and thus establish 
a connection with no media.

OR, the UAS can return an error, such as 415, if it doesn't want to 
participate in a call with no media.

I think you will find many/most audio UAs will probably return 415 or 
some other error. It would be more forgiving of them to accept the call 
and just treat it as if on hold for whatever media they have.

Its really out of the hands of the UAC. It is the one that made the 
offer with no media. There is no reason for it to send a BYE when the 
UAS responds in the only way it can.

The problem with a connection without any media is: what happens next? 
As long as it stays in that state the connection is largely useless. One 
side or the other will need to do something - probably send a reINVITE 
with a new offer that *does* include one or more m-lines.

But which side should do this? Either side could. I'm thinking that the 
UAS, if it didn't already reject the call, would immediately send a 
reINVITE with its default offer. If it can't get some media accepted, 
then it will probably reject the call.

Of course the UAC could also immediate send another offer with media. 
But if it wanted to do that, presumably it would have already done so.

The bottom line is that when you send an initial INVITE, you should 
offer all the media you are prepared to use for the call, even ones you 
want to start on hold. Or else you should send an INVITE without any 
offer. There is no real benefit to hiding media you intend to use.

Thanks,
Paul

> On Fri, Sep 17, 2010 at 10:22 PM, Pavesi, Valdemar (NSN - US/Irving)<
> valdemar.pav...@nsn.com>  wrote:
>
>> Do you want put on hold/resume ?
>> Or
>>
>> Do you want send a negative test without sdp-m-parameter. ?
>>
>>
>>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Tom
>> Kristensen
>> Sent: Friday, September 17, 2010 10:18 AM
>> To: anand madhab
>> Cc: Tom Kristensen; Sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] sdp missing m line
>>
>> On 17 September 2010 13:46, anand madhab  wrote:
>>> Hi,
>>>
>>> I have a query.
>>>   If m line is missing in invite request and 180, 200 response then what
>>> will be senario ?
>>> I dont understand the case, I mean i want to make a call with initially
>>> putting a person in hold ? please explain
>>> does caller need to reject the call
>>
>> I don't understand your case either! Please, elaborate and add more
>> details for us to understand what you mean.
>>
>> -- Tom
>>
>> ___
>> 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 missing m line

[Paul Kyzivat]

On 9/17/2010 7:45 AM, anand madhab wrote:
> Hi, If m line is missing in invite request and 180, 200 response then what
> will be senario ?
> I dont understand the case, I mean i want to make a call with initially
> putting a person in hold ? please explain
> does caller need to reject the call

Your question isn't entirely clear. Can you show call flow?

I am guessing that the INVITE has SDP with one m-line, and the response 
has SDP with no m-line ???

If so, I would expect the caller to send BYE and drop the call. The 
answer SDP must have the same number of m-lines as the offer.

We don't usually specify behavior for non-conforming cases (which this 
is), so the caller isn't *required* to send a BYE. But behavior after 
that is undefined.

Are you implementing the UAS, and wanting to prevent media from flowing 
immediately as the call is established?

You can do a number of things, depending on exactly what you want to happen:

- you can respond with an answer with matching m-line, with real address 
and port, and include an a=sendonly or a=inactive to prevent media from 
flowing to you. You have indicated that you are willing to use this 
media, but not yet. In case of RTP-based media, *RTCP* will still flow.

- you can respond with an answer with matching m-line, and a non-zero 
port, but with an address (c=) of 0.0.0.0. This is similar to prior, 
except nothing will flow to you.

- you can respond with an answer with matching m-line, with a zero port. 
This says you are rejecting the use of this media, but haven't rejected 
the call. This is valid in principle, but its likely to upset some UAs, 
because they don't know what they are supposed to do.

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

Re: [Sip-implementors] [Sipping] To Develop SIP Server

[Paul Kyzivat]

Lakshmi,

This is an inappropriate list for this question.
I suggest you take it to sip-implementors.

Thanks,
Paul

Vijayalakshmi wrote:
> Hi,
> 
>   Iam trying to develop a SIP server in VxWorks. Please assist me 
> with how to implement SIP in my Server. Where do I get these info...
> 
> Thanks in Advance...
> 
> Lakshmi Marudhanayagam
> ___
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implement...@cs.columbia.edu for questions on current sip
> Use s...@ietf.org for new developments of core SIP
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] NOTIFY with CSeq incremented in more than one

[Paul Kyzivat]

Iñaki,

IMO you should not use CSeq this way, for a variety of reasons:

- its a "layer violation". The cseq values are pertinent at the
   dialog layer. The content of the NOTIFYs is at the application
   layer.

- if perchance the dialog is being used for something else
   (e.g. an INVITE) as well as the subscription, then there can be
   other messages in the dialog that consume CSeq values.

- you might find SBCs doing funny things as in-dialog messages
   cross them.

I know you can make a case that the latter two are weird things that 
won't happen, but you are asking for trouble. But they are examples of 
why to heed the layer separation.

If the sequencing is important to your application, then you should put 
the sequence numbers into the payload.

BTW, don't forget to take into account the rate limiting stuff.

Thanks,
Paul

Iñaki Baz Castillo wrote:
> Hi, I'm doing a custom specification in which NOTIFY's contain just
> changes rather than the whole document (as there is no concept of
> "document" at all). In this case I need that the watcher receives
> always a NOTIFY with CSeq incremented in eactly one. If last received
> NOTIFY had CSeq=12 and the watcher receives a NOTIFY with CSeq=14 it
> means that it has lost some change, which is not suitable for my
> specification.
> 
> So, how can achieve it? I wouldn't like to rely on a "version"
> parameter into the notification body as there is no concept of
> "version" at all (since there is no concept of "document").
> 
> Any suggestion please? Thanks a lot.
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] UA sending REGISTE Reqeust with Route header

[Paul Kyzivat]

Siddhardha Garige wrote:
> Hello all,
> 
> I have a specific requirement to route REGISTER requests through a set a 
> predefined proxies to REGISTRAR. Can we configure UAs with this information 
> and generate a REGISTER request with Proxy1 and Proxy2 in route headers. 
> 
>  RFC 3068 "SIP extension header fields for service route discovery during 
> registration" suggests this route head has to be learned from 200 OK to 
> registrations and use this information to populate future requests. Our 
> service providers registrar is not capable of generating 200OK with route 
> set. 
> 
> Is it ok to populate REGISTER with route test from UA config information?

Yes.

> Thanks in advance.
> 
> -Sid 
> 
> 
> 
> 
> "May the light be with you."  __
> Siddhardha Garige
> www.luminepixels.com
> 
> 
> 
> 
>   
> ___
> 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] Early dialog forking

[Paul Kyzivat]

Eduardo Martins wrote:
> Hello, trying to clarify thoughts with early dialog forking, generally
> is there such concept?
> 
> For instance when receiving two 180s with different tags, should:
> 
> a) 2 early dialogs be "constructed" (why? is there any need to a
> REQUEST to be sent before receiving 2xx response which needs the
> tags?)
> 
> or
> 
> b) the remote tag should be ignored till final response arrives,
> (cancel and pracks will not set a remote tag at all)

(a) is the correct answer.

You *may* need to send requests in an early dialog.
For instance, a reliable provisional response requires a prack to be 
sent in the dialog. Also in some cases an UPDATE may need to be sent to 
carry an additional offer.

Exactly what it means for you to "construct" the early dialog is 
technically up to you. But you need to retain sufficient state.

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 body with very long lines: a problem?

[Paul Kyzivat]

Another possibility is that dropping messages with long lines is an 
explicit policy of the ALG, rather than just being a crappy 
implementation. If so, then the responsibility lies with whoever set the 
policy.

Thanks,
Paul

Paul Kyzivat wrote:
> 
> Iñaki Baz Castillo wrote:
>> Hi, in case a SIP message (i.e. MESSAGE text/plain) contains a very
>> long line in the body (a long text with no line breaks), could it
>> become a problem?
>>
>> Unfortunately I've seen some SIP ALG routers dropping SIP messages if
>> they contain long lines in the message body, but I expect that is an
>> issue in the SIP ALG router itself.
>>
>> Any comment please? Thanks a lot.
> 
> crappy implementations.
> 
> They need to just get over it and do the right thing.
> There is one certainty about the length of lines, headers, parameters, 
> etc.: None of them will be any longer than the message as a whole.
> If you have managed to read the message so you can parse it, you should 
> be able to handle any piece of it without imposing length constraints 
> that are not imposed by the syntax.
> 
> Of course, in certain cases something may exceed some other 
> uncontrollable bound on another part of the system. E.g. If your MESSAGE 
> is being gatewayed to SMS which imposes its own limit on how long the 
> content can be. But that is a different sort of a problem than an ALG 
> barfing on the message.
> 
>   Thanks,
>   Paul
> ___
> 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 body with very long lines: a problem?

[Paul Kyzivat]

Iñaki Baz Castillo wrote:
> Hi, in case a SIP message (i.e. MESSAGE text/plain) contains a very
> long line in the body (a long text with no line breaks), could it
> become a problem?
> 
> Unfortunately I've seen some SIP ALG routers dropping SIP messages if
> they contain long lines in the message body, but I expect that is an
> issue in the SIP ALG router itself.
> 
> Any comment please? Thanks a lot.

crappy implementations.

They need to just get over it and do the right thing.
There is one certainty about the length of lines, headers, parameters, 
etc.: None of them will be any longer than the message as a whole.
If you have managed to read the message so you can parse it, you should 
be able to handle any piece of it without imposing length constraints 
that are not imposed by the syntax.

Of course, in certain cases something may exceed some other 
uncontrollable bound on another part of the system. E.g. If your MESSAGE 
is being gatewayed to SMS which imposes its own limit on how long the 
content can be. But that is a different sort of a problem than an ALG 
barfing on the message.

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

Re: [Sip-implementors] Infinite Number of RTP payload in "mline"

[Paul Kyzivat]

Nitin Kapoor wrote:
> Thanks for your reply.
> 
> I checked the RFC and noticed that it does not limit the codec #s in mline,
> but nor does it comment on infinite number of codecs support being
> mandatory.
> 
> So could you please let me know whether it is mandatory to support them or
> not. Because if my SBC is not supporting this then i cannot go and ask them
> to support this.

Well, the number is far from infinite. There are only 128 possible 
payload types, so you shouldn't see more than that many values.

Since there is a reasonable upper bound, it shouldn't be so hard to support.

The device that sent you this clearly thought it was something they were 
prepared to deal with. You can refuse the ones you don't like, so what 
is the problem?

Thanks,
Paul

> Thanks,
> Nitin Kapoor
> 
> 
> 
> On 1 September 2010 13:00, Sameer Sawhney  wrote:
> 
>> As per spec 2327 this is valid ! check fmt.
>>
>>
>>   media-field = "m=" media space port ["/" integer]
>> space proto 1*(space fmt) CRLF
>>
>>   media =   1*(alpha-numeric)
>> ;typically "audio", "video", "application"
>> ;or "data"
>>
>>   fmt = 1*(alpha-numeric)
>> ;typically an RTP payload type for audio
>> ;and video media
>>
>>   proto =   1*(alpha-numeric)
>> ;typically "RTP/AVP" or "udp" for IP4
>>
>>   port =1*(DIGIT)
>> ;should in the range "1024" to "65535" inclusive
>> ;for UDP based media
>>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu
>> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Nitin
>> Kapoor
>> Sent: Wednesday, September 01, 2010 7:21 PM
>> To: sip-implementors@lists.cs.columbia.edu; s...@ietf.org
>> Subject: [Sip-implementors] Infinite Number of RTP payload in "mline"
>>
>> Dear All,
>>
>> I am facing the problem where one of source is sending bunch of RTP payload
>> in "mline", and because of that my MSX is stripping 2 codec from that line,
>> when its forwarding that OFFER to termination end.
>>
>> This is the "mline" which i am getting from source:
>>
>> *m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3
>> 56
>> 118 101 13 120*
>>
>> This is what my MSX is sending to termination after stripping the payload
>> from "mline"
>>
>> *m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42 43 44 45 46 47 4 80 3
>> 56
>> 118 101*
>>
>> Now i checked some documents but unable to find anything which says its
>> correct or not.
>>
>> Could any one please give some direction on this whether such amount of
>> payload type is correct in "mline" or it not acceptable .
>>
>> Thanks,
>> Nitin Kapoor
>> ___
>> 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] Query on Forking

[Paul Kyzivat]

I don't have 2543 committed to memory and am not motivated to go read it 
right now. But as Brett says, I think you can get a 180 w/o to-tag from 
a 2543 compatible UAS. If you subsequently get a 1xx with a to-tag then 
I guess you have two early dialogs. (But I'm not certain 2543 had the 
notion of early dialogs.) Presumably you could get a 200 w/o to-tag, and 
another with to-tag. In that case you would have to confront two dialogs.

But are there any UAs out there today that support 2543 and not 3261? 
Its been a *log* time.

Thanks,
Paul

Brett Tate wrote:
>> Is 180 response received without TO tag a forked response?
> 
> A 18x without To tag is non compliant; see rfc3261 section 8.2.6.2.  Thus the 
> UAC has to decide how it wants handle the abnormal situation.
> 
> RFC 2543 did not always require tags to form dialogs; however RFC 3261 does.  
> Thus various vendors likely handle the abnormal situation differently.  
> 
> 
> ___
> 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] Using SIP OPTIONS Message with IMS

[Paul Kyzivat]

Sameer Sawhney wrote:
> Hi Paul,
> 
> The draft document talks about procedures to check operational status of SIP
> elements which support OPTIONS.
> 
> In network, there might be some SIP elements which do not support OPTIONS
> and they will respond appropriately with 405 (Method Not Allowed) to OPTIONS
> ping, proving that they are operational and can process further requests.

OPTIONS is required to implement in 3261. (See section 11.)

> So I think there should not be any limitation that remote end point MUST
> support OPTIONS in order to check the operational status. 
> 
> In case remote end point does not support OPTIONS, this should not bar the
> originating sip element to send further requests.
> 
> Regards
> Sameer Sawhney
> 
> 
> Extract:
> 
> To comply with procedures described in this
> document, all SIP entities, including SIP user agents and proxy
> servers, MUST support the OPTIONS message when received outside of a
> dialog in accordance with this memo.
> 
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul E.
> Jones
> Sent: Wednesday, August 25, 2010 9:36 PM
> To: 'mustafa rifaee'; sip-implementors@lists.cs.columbia.edu
> Cc: Gonzalo Salgueiro
> Subject: Re: [Sip-implementors] Using SIP OPTIONS Message with IMS
> 
> Mustafa,
> 
> Not specific to IMS, there is a general need to query for operational
> status.  Unfortunately, we're finding every variant of SIP (or even products
> targeted for the same environment) use OPTIONS to query for operational
> status, but they all do it differently.  What we're trying to do is write a
> document or two that defines something everybody can live with.
> 
> Here's the draft we currently have:
> http://tools.ietf.org/html/draft-jones-sip-options-ping
> 
> Marius is also working on text for in-dialog OPTIONS and, unfortunately,
> I've not had a moment to review what was produced.
> 
> Paul
> 
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of mustafa rifaee
>> Sent: Wednesday, August 25, 2010 11:17 AM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: [Sip-implementors] Using SIP OPTIONS Message with IMS
>>
>> Hello all;
>> i would ask you about the draft of  Using OPTIONS to Query for Operational
>> Status in SIP.
>> Can we use OPTIONS message with IMS  to  Query for Operational Status in
>> SIP?
>>
>> Please Help me;
>> Thanks
>> Mustafa
>> ___
>> 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
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Proper dialog matching - URI vs. tag

[Paul Kyzivat]

Brett,

Yes, 3261 has all those MUSTs in it. But it was there for 2543 
compatibility. AFAIK there is nothing that calls for checking that the 
URIs remain unchanged as a requirement for recognizing that the request 
is an in-dialog request.

So I think it might be within the letter of the law to reject the 
request with a 400 because it isn't valid. But absent that I would 
expect it to accept the request. Returning 481 is IMO wrong.

Of course it could pretend to be only 2543 compliant. But then, IIRC, it 
should not have returned a to-tag during dialog establishment.

So I think both the proxy and the gw are behaving improperly.

Thanks,
Paul

Brett Tate wrote:
> RFC 3261 does not allow the To/From uri matching values to change within a 
> dialog.  RFC 4916 provides the ability to alter To/From uri matching values; 
> however it requires the support/use of option-tag “from-change”.  Except per 
> RFC 4916, I’m not aware of an RFC which has officially deprecated the To/From 
> rules mandated by RFC 3261 section 12.2.1.1.
> 
> RFC 3261 section 12.2.1.1:
> 
> "A request within a dialog is constructed by using many of the
>  components of the state stored as part of the dialog.
> 
>  The URI in the To field of the request MUST be set to the remote URI
>  from the dialog state.  The tag in the To header field of the request
>  MUST be set to the remote tag of the dialog ID.  The From URI of the
>  request MUST be set to the local URI from the dialog state.  The tag
>  in the From header field of the request MUST be set to the local tag
>  of the dialog ID."
> 
> 
> 
> ___
> 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] 100 Trying for REFER

[Paul Kyzivat]

You should tell the phone vendors to do a better job of implementing REFER.

What do they do? Just send a BYE on their own call as soon as they 
receive a 2xx for the REFER?

If you *really* want to make it work despite the behavior of the phone, 
you might consider:

- capture the important info from the REFER and then return a failure
   for it.

- initiate the transfer yourself.

- if it succeeds, send a bye to the referring phone.

- if it fails, send a reinvite to the referring phone to reinstate
   the original call. (Assuming it had been on hold.)

Aside for doing something extreme like that, I think you must let the 
originating phone live or die by the quality of its REFER implementation.

Thanks,
Paul

M. Ranganathan wrote:
> On Tue, Aug 17, 2010 at 4:10 PM, Paul Kyzivat  wrote:
>>
>> M. Ranganathan wrote:
>>> On Tue, Aug 17, 2010 at 9:50 AM, Paul Kyzivat  wrote:
>>>> M. Ranganathan wrote:
>>>>> Hello,
>>>>>
>>>>> I am implementing a B2BUA ITSP bridge that bridges a PBX with an ITSP.
>>>>> In one of the call flows, I get a REFER from the PBX which I have to
>>>>> convert to an INVITE. The INVITE could take a long time to return OK (
>>>>> human in the loop ) or it could fail if there is a processing error. I
>>>>> need to delay returning 202 or DECLINED  to REFER until I know the
>>>>> outcome of the INVITE. To keep the REFER client transaction alive, I
>>>>> propose to send 100 responses periodically. I assume that would keep
>>>>> the REFER client transaction in PROCEEDING state.
>>>>>
>>>>>  What would be a recommended frequency?
>>>> You must not use provisional responses for non-INVITE transactions. (See
>>>> RFC
>>>> 4320).
>>>>
>>>> The response to REFER is not supposed to be delayed until the resulting
>>>> action is complete. It should be sent as soon as you have decided to
>>>> accept
>>>> the refer.
>>>>
>>>> The outcome of the resulting INVITE is reported via NOTIFY to the
>>>> implicit
>>>> subscription that results from the REFER.
>>>>
>>>>   Thanks,
>>>>   Paul
>>>>
>>> The problem is that the entity sending the 202 is a B2BUA (not a UA).
>>> So if it blindly sends 202 it has no notion of what the transfer
>>> target will do at that point, the transfer controller assumes the
>>> transfer is done and cannot recover the transferee. The effect we want
>>> is for the transfer controller to roll back to the transferee if the
>>> transfer fails.
>>>
>>> How does one deal with that?
>> Is the B2BUA forwarding the REFER to the transfer target?
> 
> No.
> 
>> Or is it carrying out the REFER itself, using 3pcc, by sending a new INVITE
>> to the Refer-To, and then splicing things together? (I gather so.)
> 
> Correct
> 
>> If so, then I presume its the invite to the Refer-To URL that will take a
>> long time. That is the same as might be the case if there were no B2BUA and
>> you just sent a REFER to a peer UA.
>>
>> This really is what the implicit subscription and its NOTIFYs are for. You
>> can send NOTIFY messages indicating the progress of the INVITE. And if it
>> fails, you notify about that too. Then the Refering UA can take the call
>> back. (Actually it had the call all the time. It just then forgets about
>> sending BYE and goes back to interacting with it.)
> 
> Phones seem to be bad at handling that. (at least in the consultative
> transfer case).Very clunky call recovery.  I found that delaying
> sending REFER 202 until the transfer target picks up is a smoother
> user experience (at least for Polycomm phones). Of course this is
> nothing to do with the protocol operation and much more to do with the
> way the phone behaves. This could aso be different for different
> phones.
> 
> There is another problem here. Phones ( polycomm phones in particular
> ) are set up so you can hit the transfer button on a consultative
> transfer even before the potential transfer target answers (the
> infamous "consultative transfer turned blind" case). This is very
> annoying for a B2BUA because the transfer target dialog is in an EARLY
> state when the transfer is requested and hence no in-dialog requests
> can be sent down that path. I would like to at least trap such a
> condition and return REFER 603 but alas, I have no idea that the
> transfer agent is going to act this way until the potential transfer
> target has picked up the phone. INVITE has a much longer lifetime than
> REFER unfortunately, and hence I cannot delay sending REFER 202 ( or
> REFER 603) else the REFER transaction times out.  In fact this is the
> use case that lead me to wonder if the REFER client transction could
> be kept alive by sending 100 responses periodically. I think the
> answer I am hearing is "No"
> 
> Thanks for your help.
> 
> Ranga
> 
> 
>>Thanks,
>>Paul
>>
>>
> 
> 
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] "a=" attribute in media and session (SDP)

[Paul Kyzivat]

Sagar,

Think of it like declarations in nested scopes in a programming language.

The outer (session level) scope applies except where overridden by a 
redeclaration in an inner (media level) scope.

This applies to a lot, but not all, attributes. (The ones that may be 
used at "both" session and media level. IMO it *ought* to apply to them 
all, but that is another story.) It also applies to c=.

Thanks,
Paul

sagar sheth wrote:
> Hello Friends,
> 
> I have query regarding the usage of "a=" attribute at session and media
> level. Anything above m line in SDP is considered in session and below m
> line is considered as media.
> "a" which defines the direction of the stream can be used in media and
> session. So my questions are
> 
>>> What is difference/advantage of using "a" in media over session?
> Is it if more than media stream is present, its direction can be
> treated Independently?
> 
>  >>Also What if "a" is present at both media & session level?
> 
> Thanks!
> Sagar
> ___
> 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] 100 Trying for REFER

[Paul Kyzivat]

M. Ranganathan wrote:
> On Tue, Aug 17, 2010 at 9:50 AM, Paul Kyzivat  wrote:
>>
>> M. Ranganathan wrote:
>>> Hello,
>>>
>>> I am implementing a B2BUA ITSP bridge that bridges a PBX with an ITSP.
>>> In one of the call flows, I get a REFER from the PBX which I have to
>>> convert to an INVITE. The INVITE could take a long time to return OK (
>>> human in the loop ) or it could fail if there is a processing error. I
>>> need to delay returning 202 or DECLINED  to REFER until I know the
>>> outcome of the INVITE. To keep the REFER client transaction alive, I
>>> propose to send 100 responses periodically. I assume that would keep
>>> the REFER client transaction in PROCEEDING state.
>>>
>>>  What would be a recommended frequency?
>> You must not use provisional responses for non-INVITE transactions. (See RFC
>> 4320).
>>
>> The response to REFER is not supposed to be delayed until the resulting
>> action is complete. It should be sent as soon as you have decided to accept
>> the refer.
>>
>> The outcome of the resulting INVITE is reported via NOTIFY to the implicit
>> subscription that results from the REFER.
>>
>>Thanks,
>>Paul
>>
> 
> The problem is that the entity sending the 202 is a B2BUA (not a UA).
> So if it blindly sends 202 it has no notion of what the transfer
> target will do at that point, the transfer controller assumes the
> transfer is done and cannot recover the transferee. The effect we want
> is for the transfer controller to roll back to the transferee if the
> transfer fails.
> 
> How does one deal with that?

Is the B2BUA forwarding the REFER to the transfer target?
Or is it carrying out the REFER itself, using 3pcc, by sending a new 
INVITE to the Refer-To, and then splicing things together? (I gather so.)

If so, then I presume its the invite to the Refer-To URL that will take 
a long time. That is the same as might be the case if there were no 
B2BUA and you just sent a REFER to a peer UA.

This really is what the implicit subscription and its NOTIFYs are for. 
You can send NOTIFY messages indicating the progress of the INVITE. And 
if it fails, you notify about that too. Then the Refering UA can take 
the call back. (Actually it had the call all the time. It just then 
forgets about sending BYE and goes back to interacting with it.)

Thanks,
Paul

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

Re: [Sip-implementors] 100 Trying for REFER

[Paul Kyzivat]

M. Ranganathan wrote:
> Hello,
> 
> I am implementing a B2BUA ITSP bridge that bridges a PBX with an ITSP.
> In one of the call flows, I get a REFER from the PBX which I have to
> convert to an INVITE. The INVITE could take a long time to return OK (
> human in the loop ) or it could fail if there is a processing error. I
> need to delay returning 202 or DECLINED  to REFER until I know the
> outcome of the INVITE. To keep the REFER client transaction alive, I
> propose to send 100 responses periodically. I assume that would keep
> the REFER client transaction in PROCEEDING state.
> 
>  What would be a recommended frequency?

You must not use provisional responses for non-INVITE transactions. (See 
RFC 4320).

The response to REFER is not supposed to be delayed until the resulting 
action is complete. It should be sent as soon as you have decided to 
accept the refer.

The outcome of the resulting INVITE is reported via NOTIFY to the 
implicit subscription that results from the REFER.

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

Re: [Sip-implementors] Transport Switching scenario by proxy

[Paul Kyzivat]

$...@r\/|>r!`/@ wrote:
> Hi All,
> 
> Can you please refer me a write up which explains how a proxy handles
> transport switching scenarios if required which frwding request.

Can you be more specific about your question?

Each hop is a separate sip transaction. Each must make a decision about 
the transport to use. Those are independent decisions. If the transport 
selected for the outbound hop happens to be different than that used for 
the inbound hop, then I guess you would say that there has been 
"transport switching".

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

Re: [Sip-implementors] Target refresh of an INVITE initiated dialog

[Paul Kyzivat]

Iñaki Baz Castillo wrote:
> 2010/7/6 Paul Kyzivat :
>>> What does it mean "a subscription and invite usage are sharing a
>>> dialog"? does it mean two dialog, an INVITE dialog and a SUBSCRIBE
>>> dialog, sharing the same From/to-tags and Call-ID? how could it be
>>> useful such "experiment"??
>> It means one dialog (Callid, from-tag, to-tag) and two distinct usages of
>> that - e.g. INVITE and SUBSCRIBE.
>>
>> The easiest way to encounter that in the wild is to send a REFER in an
>> INVITE-dialog-usage, thus getting an (implicit) subscribe-dialog-usage to
>> the refer event in the same dialog.
> 
> Yes, I know that usage. But in the above text I understood sending a
> initial SUBSCRIBE with same dialog info than an existing INVITE
> dialog. :)

If you send an "initial" SUBSCRIBE with the dialog id of an existing 
dialog, then it is not really an "initial" SUBSCRIBE - it is an 
in-dialog SUBSCRIBE. Its "initial" WRT the dialog-*usage* establishment, 
but not WRT the *dialog* establishment.

Its technically valid according to 3261 & 3265, though frowned upon and 
to be forbidden by 3265bis.

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

Re: [Sip-implementors] Target refresh of an INVITE initiated dialog

[Paul Kyzivat]

Iñaki Baz Castillo wrote:
> 2010/7/6 Jean-Hugues Royer :
>> If a subscription and invite usage are sharing a dialog, sending a
>> refresh SUBSCRIBE with a different contact will cause reINVITEs from the
>> peer to go to that different contact.
> 
> What does it mean "a subscription and invite usage are sharing a
> dialog"? does it mean two dialog, an INVITE dialog and a SUBSCRIBE
> dialog, sharing the same From/to-tags and Call-ID? how could it be
> useful such "experiment"??

It means one dialog (Callid, from-tag, to-tag) and two distinct usages 
of that - e.g. INVITE and SUBSCRIBE.

The easiest way to encounter that in the wild is to send a REFER in an 
INVITE-dialog-usage, thus getting an (implicit) subscribe-dialog-usage 
to the refer event in the same dialog.

Thanks,
Paul

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

Re: [Sip-implementors] Target refresh of an INVITE initiated dialog

[Paul Kyzivat]

Jean-Hugues Royer wrote:
> Hi,
> 
> 
> RFC5057 says:
> Target refresh requests update the remote target of a dialog when they 
> are successfully processed.
> The currently defined target refresh requests are INVITE, UPDATE, 
> SUBSCRIBE, NOTIFY, and REFER
> The remote target is part of the dialog state. When a target refresh 
> request affects it, it affects it for ALL usages sharing that dialog.
> If a subscription and invite usage are sharing a dialog, sending a 
> refresh SUBSCRIBE with a different contact will cause reINVITEs from the 
> peer to go to that different contact.
> 
> but RFC3261 says:
> For dialogs that have been established with an INVITE, the only target 
> refresh request defined is re-INVITE (see Section 14).
> Other extensions may define different target refresh requests for 
> dialogs established in other ways.
> 
> 
> So my question is this, can you confirm me that an INVITE initiated 
> dialog will update its remote target when it receives any SUBSCRIBE, 
> NOTIFY or REFER request ?

Assuming such a request is sent within the existing dialog, then yes, 
the target is to be refreshed.

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 exchange with multiple steps

[Paul Kyzivat]

Marcus,

responses inline...

Marcus Better wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 2010-07-01 19:35, Paul Kyzivat skrev:
>> Marcus Better wrote:
>>> I'm considering to apply SIP in an application, but using a custom
>>> session description format that is not SDP. The endpoints must be able
>>> to exchange longer sequences of offers before reaching an agreement,
> 
>> Yes, its possible.
>>
>> But I suggest you think long and hard before abandoning SDP in favor of
>> a different session description format.
> 
> I'm not setting up a media session, but some more general type of
> "session". Interoperability with SIP/RTP is not a goal. But I would like
> to have some other features of SIP:
> * user initiating a session setup with other user(s),
> * answering or cancelling a session.
> * forking and parallel search.
> * conference (multi-party, adding and removing participants).
> 
> By using SIP we hope to gain ability to reuse existing protocol and
> network elements (routers, proxies, app servers) with minimum effort.
> 
> Unfortunately I'm not able to give full details here.

ok.

>>> I'm considering to use a sequence of reliable provisional responses and
>>> PRACKs, each carrying a session description, and repeating until the
>>> session parameters are agreed.
> 
>> You don't spell out in the above which messages have offers and answers,
> 
> To be more precise:
> * both sides take turns in sending offers,
> * there is at least one offer,
> * the sequence ends with an answer, which means the most recent offer
> was accepted.

sip o/a requires a sequence (one or more) o/a *pairs*. So its always 
oaoaoa and cannot ever be ...ooa... or ...oaa...

I can't tell from the above if you are compliant with that or not.

(It is IMO a defect in sip that there is nothing about a message that 
distinguishes an offer from an answer. It can only be determined from 
history - a session description is an answer if it was preceded by an 
offer, and visa versa.)

> There is another important restriction: there is user interaction after
> each offer, so there might be an extended waiting time before each
> message (not just the INVITE).

> I guess this rules out carrying messages in a PRACK.

So it would seem.

> I could still use
> reliable provisional responses in the UAS-->UAC direction. Not sure
> about the UAC-->UAS though. Maybe an UPDATE could carry an offer, its
> 200 OK response would not carry an offer, and a further provisional
> response would carry the next offer from the UAS.

The latter isn't permitted.

>> There are limited ways you can insert offers and answers into these.
>> Take a look at:
>>
>> http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-13.txt
> 
> I did, but the different scenarios it describes are all restricted to
> one round-trip for the offer/answer.

I think you will find some of the scenarios actually mention 2 or 3 o/a 
exchanges. And certainly it is intended to cover cases involving more 
than one exchange. Its just that what it focuses on only addresses more 
than one for context.

The key thing for you in that document is Table 1, because it summarizes 
the constraints under which you may operate.

I never considered a use case such as yours. It seems that the 
constraints don't in fact permit you to do the o/a exchanges as you 
wish. After the first exchange, there is no way to put a large delay 
between an offer and an answer. (Unless of course you want to use a 
sequence of reINVITEs. But I presume that is off the table.)

> SDPng is interesting, but only considers a two-step offer/answer when
> used with SIP.
> 
>> Also, look at RFCs 3312,
> 
> Ok, here they use UPDATE  along the same lines. This looks promising...

I suggest you look at this carefully.
Preconditions have some of the constraints you do - it may take time to 
resolve them. But they put the delays between the o/a pairs rather than 
between the o and a of a pair.

Thanks,
Paul

> Thanks a lot for you comments, this is very helpful!
> 
> Cheers,
> 
> Marcus
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkwt91AACgkQXjXn6TzcAQnJ5QCg3xFhnskuZlEkGpwuoTDx3aqu
> GD8AoO0taGAU0y+vxSMvLY0WNUUCfvX0
> =lZxO
> -END PGP SIGNATURE-
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] offer/answer exchange with multiple steps

[Paul Kyzivat]

Marcus Better wrote:
> Hi,
> 
> I'm considering to apply SIP in an application, but using a custom
> session description format that is not SDP. The endpoints must be able
> to exchange longer sequences of offers before reaching an agreement, not
> just two (offer and answer) as in RFC3264. Is it possible to use SIP in
> such a scenario?

Yes, its possible.

But I suggest you think long and hard before abandoning SDP in favor of 
a different session description format. That will cut you off from 
interop with the rest of the world.

I know SDP is limited and ugly. But in spite of that it has been 
stretched to cover a lot of stuff.

Some time ago there was a proposal for SDPng which was to be the 
successor to SDP. It was "modern" with xml encoding and lots of fancy 
new features, plus being a functional superset of SDP.

But it was eventually abandoned because no one could come up with a 
workable migration plan nor a way to motivate migrating.

Why don't you try spelling out what it is you are trying to do that 
leads you to take this approach. Maybe someone will have a suggestion 
for another way to accomplish the same thing.

> I'm considering to use a sequence of reliable provisional responses and
> PRACKs, each carrying a session description, and repeating until the
> session parameters are agreed.
> 
> Sample flow:
> 
> UAC UAS
>  |   |
>  INVITE
> - ->
> 
>   183 Session Progress
> <-
>  PRACK
> - ->
> 
>   183 Session Progress
> <-
>  PRACK
> - ->
> 
>  200 OK
> <-
>   ACK
> - ->
> 
> 
> Is this a workable solution?

You don't spell out in the above which messages have offers and answers, 
and that matters to whether this is workable. Also, you don't show the 
200 responses to the PRACKs.

There are limited ways you can insert offers and answers into these. 
Take a look at:

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

Also, look at RFCs 3312, 4032, and 5027 on preconditions which will give 
you examples of multiple o/a exchanges.

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

Re: [Sip-implementors] Registration renewal in the middle of the call

[Paul Kyzivat]

Adding to what Dale said:

Even in 3gpp, a registration failure should not cause a deregistration. 
Rather, state should be the same as if you hadn't done it at all.
So as long as you eventually get it right before the registration 
succeeds you should not have a problem.

Of course, if you waited too long, and the registration times out 
between your failed attempt and a successful one, then you would see a 
problem. But I doubt that is your case - it would be a huge coincidence.

More likely the registrar is broken and is unregistering you when your 
renewal fails.

Thanks,
Paul

WORLEY, Dale R (Dale) wrote:
> 
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Vivek Singla 
> [vivsin...@yahoo.com]
> 
> 1) Should the Register renewal have the empty nonce. I think it should have 
> the same nonce as the INVITE.
> 
> 2) Should the call be dropped after 401 for the registration renewal? I am 
> thinking since the Register renewal did eventually got the 200OK, may be MTA 
> should have kept the call alive.
> ___
> 
> 1) The renewal can use any nonce it prefers.  In many systems, the nonces 
> time out much quicker than the time between successive registration renewals, 
> so there isn't a lot to be gained by keeping the nonce around for 
> registrations alone.
> 
> 2) Your example is 3GPP, and it has a number of perversions.  But in ordinary 
> SIP, it would be considered an error for a UA to drop a call because its 
> registration failed.  Indeed, registration and making outgoing calls are 
> entirely independent processes.
> 
> 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] Request for offer-SDP before answer

[Paul Kyzivat]

There isn't any way to do this.

Thanks,
Paul

honsha.nara...@wipro.com wrote:
> Hi , 
> 
> Question :- Is there any standardized mechanism where a SIP UA "B" can
> request an offer SDP from  party "A" [or any direction] before the call
> is established ( I mean before 200 OK/ACK for Invite )  ? 
> 
> Let me clarify: for an answered/established call, we can send an Invite
> with empty SDP to get the SDP back from an UA (3PCC style). 
> But we can't do the same thing with an 18x message or an
> UPDATE/INFO/PRACK with empty SDP!!  Can we?? 
> 
> Assumption:- 
>   a) We already finished one (more than one) offer-answer
> transaction. 
>   b) My situation demands that I need a fresh un-negotiated SDP
> from party A or B during ringing state!! 
> 
> 
> Thanks and Regards,
> Honsha 
>  
> 
>  
> 
> Please do not print this email unless it is absolutely necessary. 
> 
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments. 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should 
> check this email and any attachments for the presence of viruses. The company 
> accepts no liability for any damage caused by any virus transmitted by this 
> email. 
> 
> www.wipro.com
> 
> ___
> 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] Out for an hour or two

[Paul Kyzivat]

Have to go out for appointment.
Hope to be back before AXP meeting.

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

Re: [Sip-implementors] UPDATE method without any SDP

[Paul Kyzivat]

As has been noted, it can be used in this form to revise the Contact 
address, and it may be used to refresh a session-timer. INFO is no good 
for either of those things.

It has advantages, over reINVITE, for both of those things in that you 
can be certain that there will be no new offer/answer exchange.

THanks,
Paul

Sunil Bhagat wrote:
> Hi All,
> 
>  
> 
> I have a small query regarding UPDATE method. 
> 
> UPDATE method is used to change the session parameters. I wanted to know,
> what is the use of sending UPDATE without any sdp.
> 
>  
> 
> Thanks,
> 
> Sunil
> 
> ___
> 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] Sending 180 Ringing with Require:100rel but no SDP

[Paul Kyzivat]

Anjana Arora wrote:
> Hi,
> 
> As per RFC 3262, Sec 5 "The Offer/Answer Model and PRACK"
>  
> “If the INVITE contained an offer, the UAS MAY generate an answer in a 
> reliable provisional response (assuming these are supported by the UAC). That 
> results in the establishment of the session before completion of the call.  
> Similarly, if a reliable provisional response is the first reliable message 
> sent back to the UAC, and the INVITE did not contain an offer, one MUST 
> appear in that reliable provisional response.”

That section doesn't apply here because the INVITE did not contain an offer.

Thanks,
Paul

> Regards,
> Anjana
> 
> 
> 
> - Original Message 
> From: "Klatsky, Carl" 
> To: sip-implementors@lists.cs.columbia.edu
> Sent: Fri, November 6, 2009 12:03:13 AM
> Subject: [Sip-implementors] Sending 180 Ringing with Require:100rel but no SDP
> 
> Hi,
> 
> I have been reviewing RCF 3261 & 3262  trying to find an answer to this
> question:
> 
> Is ever valid to send a 180 Ringing with the Require: 100rel header, but
> without an SDP?  The call flow in question is like this
> 
> 1. INVITE with no SDP and Supported: 100rel <--
> 2. 180 Ringing with no SDP but Require: 100rel -->
> 3. PRACK with no SDP <--
> 4. 200 OK to PRACK -->
> 5. 200 OK with SDP -->
> 6. ACK with SDP <---
> 
> I am trying understand if this flow should work as listed above
> according to RFC defined behavior.
> 
> Regards,
> 
> Carl Klatsky
> 
> ___
> 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] Sending 180 Ringing with Require:100rel but no SDP

[Paul Kyzivat]

I agree with Tomasz - the 180 is the first reliable response, and so 
must contain an offer.

Thanks,
Paul

Tomasz Zieleniewski wrote:
> Hi Carl,
> 
> In Your case this flow is wrong, if there is no SDP in the initial INVITE,
> UAS must
> send and offer in the first reliable response, in Your case this is 180
> Ringing.
> The Require header with 100rel tag in the response confirms that UAS
> received
> initial INVITE with 100rel tag in Supported or Required header and that this
> 
> particular provisional response is sent reliably.
> 
> Kind regards,
> - Tomasz Zieleniewski
> --
> ICT Backyard - http://ictbackyard.com
> 
> 
> 2009/11/5 Klatsky, Carl 
> 
>> Hi,
>>
>> I have been reviewing RCF 3261 & 3262  trying to find an answer to this
>> question:
>>
>> Is ever valid to send a 180 Ringing with the Require: 100rel header, but
>> without an SDP?  The call flow in question is like this
>>
>> 1. INVITE with no SDP and Supported: 100rel <--
>> 2. 180 Ringing with no SDP but Require: 100rel -->
>> 3. PRACK with no SDP <--
>> 4. 200 OK to PRACK -->
>> 5. 200 OK with SDP -->
>> 6. ACK with SDP <---
>>
>> I am trying understand if this flow should work as listed above
>> according to RFC defined behavior.
>>
>> Regards,
>>
>> Carl Klatsky
>>
>> ___
>> 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] 183 without SDP stops the local ringing

[Paul Kyzivat]

Arunachala wrote:
> Doesn't RFC3960 talk about this very thing?

Yes. I knew that was out there, but didn't remember the number.

Thanks,
Paul

> -Arun
> 
> On Wed, May 12, 2010 at 1:14 PM, Paul Kyzivat  wrote:
>> Technically, SDP in any 18x only serves to indicate where media should
>> be *sent*, and has nothing to do with whether you should receive media,
>> play received media, etc.
>>
>> Nor does receiving a 180 mean you should play local ringback. It merely
>> says "the other end is being alerted". Nor does receiving a 183 after
>> receiving a 183 after a 180 mean you should *not* play local ringback.
>>
>> If you have received a 180, you may want to play something indicating
>> the called device is alerting. If you are receiving media that you are
>> willing to render, you might want to do so in lieu of locally generated
>> ringback.
>>
>> Unless you use ICE or SRTP, SIP doesn't really specify any way to
>> determine if media you are receiving is media the callee intended for
>> you to receive, rather than spam. As a result, some implementations
>> refuse to render received media unless it comes from the address they
>> are to send media to (symmetric RTP). You can do that if you feel you
>> must, but recognize that you may miss valid media from some implementations.
>>
>> There is no perfect answer here. You can do pretty much as you wish.
>> (E.g. you aren't *required* to render any of the media you receive, even
>> after the call is established.) But you can also have a crappy
>> implementation that doesn't interoperate well with others if you make
>> unreasonable assumptions.
>>
>>Thanks,
>>Paul
>>
>> Kanumuri, Sreeram wrote:
>>>  Nitin,
>>>
>>>> I checked the TO tag for both 18x and noticed that both are the same.
>>>> Do you think, that after sending 180 ringing(where local ringing should 
>>>> generate), if my UAS is sending 183 without SDP will stop the local 
>>>> ringing?
>>> This is up to the implementation whether to play ringing (or) not.
>>>
>>> In this case, I feel you should stop the ringing after receiving 183 and 
>>> show a different treatment to the originating UA (something like 
>>> click,,click..) to indicate that the call is in progress...
>>>
>>>
>>> HTH,
>>> Sreeram.
>>> ___
>>> 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
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] 183 without SDP stops the local ringing

[Paul Kyzivat]

Technically, SDP in any 18x only serves to indicate where media should 
be *sent*, and has nothing to do with whether you should receive media, 
play received media, etc.

Nor does receiving a 180 mean you should play local ringback. It merely 
says "the other end is being alerted". Nor does receiving a 183 after 
receiving a 183 after a 180 mean you should *not* play local ringback.

If you have received a 180, you may want to play something indicating 
the called device is alerting. If you are receiving media that you are 
willing to render, you might want to do so in lieu of locally generated 
ringback.

Unless you use ICE or SRTP, SIP doesn't really specify any way to 
determine if media you are receiving is media the callee intended for 
you to receive, rather than spam. As a result, some implementations 
refuse to render received media unless it comes from the address they 
are to send media to (symmetric RTP). You can do that if you feel you 
must, but recognize that you may miss valid media from some implementations.

There is no perfect answer here. You can do pretty much as you wish. 
(E.g. you aren't *required* to render any of the media you receive, even 
after the call is established.) But you can also have a crappy 
implementation that doesn't interoperate well with others if you make 
unreasonable assumptions.

Thanks,
Paul

Kanumuri, Sreeram wrote:
>  Nitin,
> 
>> I checked the TO tag for both 18x and noticed that both are the same.
>> Do you think, that after sending 180 ringing(where local ringing should 
>> generate), if my UAS is sending 183 without SDP will stop the local ringing?
> 
> This is up to the implementation whether to play ringing (or) not.
> 
> In this case, I feel you should stop the ringing after receiving 183 and show 
> a different treatment to the originating UA (something like click,,click..) 
> to indicate that the call is in progress...
> 
> 
> HTH,
> Sreeram.
> ___
> 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] "require" and "supported"-Header regarding reliable Responses

[Paul Kyzivat]

Michael Hirschbichler wrote:
> Thx, I got it :)
> 
> 2nd question in this context: If in an INVITE-request an "Allow: PRACK, 
> ..."-Header is set, am I correct in the assumption, that there must be a 
> "supported: 100rel"-Header too?

Logically they are distinct. So "in principle" you could support PRACK 
and not 100rel or visa versa. But it would be silly to do so because one 
is not usable without the other.

And then there is UPDATE, which is also distinct. In principle you can 
support 100rel and PRACK, but not UPDATE. But in practice both are used 
for early o/a support. Often (though not always) those using 100rel will 
expect to do multiple o/a before the INVITE completes. And its likely 
that UPDATE will be required for that.

So 100rel, PRACK, and UPDATE are really a package that ought to be 
implemented as a group.

Thanks,
Paul

> br
> Michael
> 
> Am 06.05.2010 15:45, schrieb Paul Kyzivat:
>>
>> Michael Hirschbichler wrote:
>>> Hi all,
>>>
>>> we are currently discussing if it is possible (and - esp. - allowed)
>>> to set both, a "Require:"- and a "Supported:"-Header with the
>>> "100rel"-option in the same INVITE-Request. In my opinion, if 100rel
>>> is set in the "Require:"-header, it is implicitely also supported and
>>> should not explicitely set in the "Supported:"-header.
>>> Is this assumption correct? How should a UAS react, if this option is
>>> set twice (*Supported:* and *Required*)?
>> Supported says what *you* support.
>> Require says what you expect the *other guy* to support.
>> One does not imply the other.
>>
>> In the case of 100rel, matching behavior is required on both sides.
>> If you send a Require:100rel in an INVITE, the UAS will probably
>> eventually send a reliable provisional, and it will contain
>> Require:100rel. So it would be unwise of you to send Require:100rel if
>> you don't also support it. You aren't strictly required to send
>> Supported:100rel, but if you include a Supported header and it doesn't
>> include 100rel, then the other guy is likely to conclude that you don't
>> support it.
>>
>> Thanks,
>> Paul
> 
> ___
> 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] "require" and "supported"-Header regarding reliable Responses

[Paul Kyzivat]

Michael Hirschbichler wrote:
> Hi all,
> 
> we are currently discussing if it is possible (and - esp. - allowed) to 
> set both, a "Require:"- and a "Supported:"-Header with the 
> "100rel"-option in the same INVITE-Request. In my opinion, if 100rel is 
> set in the "Require:"-header, it is implicitely also supported and 
> should not explicitely set in the "Supported:"-header.
> Is this assumption correct? How should a UAS react, if this option is 
> set twice (*Supported:* and *Required*)?

Supported says what *you* support.
Require says what you expect the *other guy* to support.
One does not imply the other.

In the case of 100rel, matching behavior is required on both sides.
If you send a Require:100rel in an INVITE, the UAS will probably 
eventually send a reliable provisional, and it will contain 
Require:100rel. So it would be unwise of you to send Require:100rel if 
you don't also support it. You aren't strictly required to send 
Supported:100rel, but if you include a Supported header and it doesn't 
include 100rel, then the other guy is likely to conclude that you don't 
support it.

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 with 2 m-lines for audio and video

[Paul Kyzivat]

I haven't examined all the details, but in principle there is nothing 
wrong with what you have done, and IMO it is reasonable to assume that 
the UAS would accept the call if it could handle at least one of the 
m-lines. However you have probably crossed the line into a realm the UAS 
isn't smart enough to deal with.

In any case, what would you do if somebody accepted two of the audio 
lines or two of the video lines? Would you be able to cope?

Thanks,
Paul

Franz Edler wrote:
> Hi all,
> 
> I have a problem with the following SDP:
> 
> v=0
> o=IWF 71 70 IN IP4 10.24.229.10
> s=H323 Call
> c=IN IP4 10.24.229.10
> t=0 0
> m=audio 10256 RTP/AVP 8 0
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000/1
> m=video 10258 RTP/AVP 31 34
> a=rtpmap:31 H261/8000
> a=rtpmap:34 H263/9/1
> m=audio 10260 RTP/AVP 15 115
> a=rtpmap:15 G728/8000
> a=rtpmap:115 genericAudio/8000/1
> m=video 10262 RTP/AVP 0 96
> a=rtpmap:0 genericVideo/8000
> a=rtpmap:96 extendedVideoCapability/9/1
> 
> It has two m-lines for audio and 2 m-lines for video.
> When the session partner does not support G.728 audio it rejects (488  
> Not acceptable) the session despite it could use PCM audio.
> 
> Is above syntax correct if in the end only one audio- and one  
> video-stream is used?
> 
> BR
> Franz
> 
> 
> 
> ___
> 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 Retransmission of Provisional response

[Paul Kyzivat]

Arunachala wrote:
> Once you see that you have already finished a "183-PRACK-200 OK"
> transaction, you can also send "unreliable" provisional response with
> the currently negotiated SDP in it.

All the 1xx responses, reliable or unreliable, to a given 
INVITE/reINVITE must carry the *same* SDP if they carry any SDP at all.

So, if there has been a single O/A exchange, with answer in a reliable 
183, you can indeed send that same SDP in subsequent unreliable 1xx 
responses. But that is not recommended. It is at best confusing. And it 
won't work if you do another O/A exchange.

The UAC need to understand that a 180 without SDP *does not* mean "stop 
playing in band media and start generating local ringback instead".

Thanks,
Paul

> -Arun
> 
> On Tue, May 4, 2010 at 11:23 AM, Pranab Bohra  wrote:
>> Hi,
>>
>> Your application can handle the situation by not generating local ring
>> back when it receives 180 without message body if it has already
>> passed on the early media to the user. Detailed explanation with
>> example provided under Section 3.2 of rfc 3960.
>>
>> Cheers,
>> Pranab
>>
>> On Tue, May 4, 2010 at 8:20 PM, zabi
>>  wrote:
>>> Arun,
>>>
>>> This requirement is targeted to to stop the proxy from canceling and
>>> serve no other purpose.
>>> So sending  an 183  would  add additional processing (183-prack-200 ok
>>> exchange) on caller and callee,  and would a network overhead.
>>>
>>> And 3262 dosent mandate sending of provisional response reliably, in
>>> this context.
>>>
>>> Pls correct if i am wrong.
>>>
>>> Regards,
>>> Zabi
>>>
>>>
>>> Arunachala wrote:
 Hi,

 RFC3262 never says "retransmit/resend" provisional response. It
 says "the UAS will need to send periodic provisional
 responses", which means it has to send NEW reliable provisional
 response. So, these CAN always carry the currently negotiated SDP for
 that call.

 -Arun

 On Tue, May 4, 2010 at 7:12 AM, zabi
  wrote:
> Dear All,
>
> We are supposed to send non-100 1xx provisional response every min as
> per 3261.
> This requirement is overwritten by rfc3262 requirement which states
> non-100 1xx
> provisional response should be sent every 2 and half min.
>
> What if there are UPDATE exchanges in between, the sdp offer might have
> been updated by these UPDATE exchanges.
> Re-sending of previous 180/183 dosent seem logical as we already have an
> updated sdp
> Sending 180 without a Message body,
> when already a 183 prack exchange is over carries a different meaning in
> my application[my application stops playing the ringtone specified in
> 183 and starts ringing!!!]
>
> So sending 180 without message body is ruled out.
> Is there any other way to handle this?
>
> Pls correct if i am wrong.
>
> Regards,
> Zabi
>
> Snippets.
>
> RFC 3261
> 13.3.1.1
> To prevent cancellation, the UAS MUST send a non-100
> provisional response at every minute, to handle the possibility of lost
> provisional responses.
>
>
> RFC3262
>  As discussed in Section 13.3.1.1 of RFC 3261, the UAS will need to send
> periodic provisional
> responses to request an "extension" of the transaction at proxies.
> The requirement is that a proxy receive them every three minutes, but
> the UAS needs to send them more frequently (once a minute is
> recommended) because of the possibility of packet loss. As a more
> efficient alternative, the UAS can send the response reliably, in
> which case the UAS SHOULD send provisional responses once every two and
> a half minutes.
>
> ___
> 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
>>>
> 
> ___
> 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 offer-answer - problem

[Paul Kyzivat]

Yes, this is legal.

 From 3264:

In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer.  Even if the same
payload type number is used, the answer MUST contain rtpmap
attributes to define the payload type mappings for dynamic payload
types, and SHOULD contain mappings for static payload types.  The

...  The answerer MUST send using a media format in the offer
that is also listed in the answer, and SHOULD send using the most
preferred media format in the offer that is also listed in the
answer.  In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer.

Each end *receives* on the payload number it supplied, and *sends* on 
the payload number it got from the other side.

Thanks,
Paul

Michael Hirschbichler wrote:
> Hi all,
> 
> we are facing the following problem with components of two different
> manufactorer and we are now wondering about the correct behaviour of the
> components:
> 
> According to RFC 3725, Flow I, we have the following dialog:
> 
>  A  Controller
>  |(1) INVITE no SDP  |
>  |<--|
>  |(2) 200 offer1 |
>  |-->|
>  |   |(3)  ...
>  |   | ...
>  |   |(4)  ...
>  |   |<--- ...
>  |   |(5)  ...
>  |   | ...
>  |(6) ACK answer1|
>  |<--|
> 
> in the sdp offer1, sent from A-party to the Controller, we have the
> following media-attribute and -description:
> offer1:
> ...
> m=audio 50364 RTP/AVP 103 18 8 0 101
> a=rtpmap:103 g726-32/8000
> ...
> 
> The response of the Controller contains these SDP-media-attribute and
> -descrription
> answer1:
> ...
> m=audio 18018 RTP/AVP 99 18 8 0 101
> a=rtpmap:99 g726-32/8000
> ...
> 
> As you can see, A-party offers "g726-32" with media-ID "103" and the
> Controller answers with "g726-32", but media-ID "99".
> 
> My questions are:
> * is this allowed?
> * if not, why?
> * if yes, how should the components behave? Should Controller send g726
> with id 103 and the A-party with ID 99?
> 
> 
> Any ideas are welcome,
> 
> br
> Michael
> ___
> 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 resolve 491 request pending cross over on Re-INVITEs

[Paul Kyzivat]

Dushyant Godse wrote:

> Now UA2 receives re-invite w/ SDP on call leg #1 from UA1. UA1 extracts
> SDP from call leg #1 and sends a Re-INVITE to UA2 on call leg#2. At the
> same time UA1 sends a re-invite on call leg#2 to UA2.  These are part of
> session refresh being triggered  using re-invites.
> 
> UA1   UA2   
> 
>  -- INVITE  w/ SDP (call leg#1)--- >
> 
> <-- INVITE  w/ SDP (call leg#2)--- 

> -- INVITE  w/ SDP (call leg#2)--- >
> 
> <--491 request pending (call leg#2)---
> 
>  -- 100 trying(call leg#2)--- >
> 
> -- 491 request pending(call leg#2)--- >
> 
> -- ACK(call leg#2)--- >
> 
> <-- ACK (call leg #2)---
> 
> Question is -
> 
> When a re-invite and 491 pending cross over happens on a dialog (call
> dialog #2), how do both the UA resolve this. What retry timers are used
> to resolve this and is there a draft available that addresses this
> issue?

You don't find 3261 section 14.1 sufficient?

If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
timer with a value T chosen as follows:

   1. If the UAC is the owner of the Call-ID of the dialog ID
  (meaning it generated the value), T has a randomly chosen value
  between 2.1 and 4 seconds in units of 10 ms.

   2. If the UAC is not the owner of the Call-ID of the dialog ID, T
  has a randomly chosen value of between 0 and 2 seconds in units
  of 10 ms.

The above still applies (independently on each dialog) when B2BUAs are 
involved. I got a little lost in your example, but I suspect you have 
the B2BUA relaying a request from one leg to the other when it ought to 
have already recognized glare and generated a 491.

The problem with the section 14.1 rules, as applied to B2BUAs comes when 
the B2BUA is the "owner" of the call-ids for two calls that it is 
coupling. The result may be that in a glare situation it may send a 491 
in both directions, and then they will both choose the backoff in range 
[0-2]. You can just ignore that and trust that they won't collide 
indefinitely, or else you can do something "special".

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

Re: [Sip-implementors] re-INVITE ACK clarification

[Paul Kyzivat]

https://datatracker.ietf.org/doc/draft-ietf-sipping-sip-offeranswer

neil corcoran wrote:
> Hi,
> 
> In an established session we receive a re-INVITE with an SDP offer
> we respond with a 200 with an SDP answer
> and the far end sends an ACK with a copy of the original SDP offer
> which is out of the ordinary for our software and caused our end to crash.
> I am inclined to pretend that the SDP in the ACK never existed and carry on.
> I've been checking RFC3261 for clarification but couldn't see anything
> definitive on this.
> Is ignoring it the correct thing to do?
> 
> Regards,
> 
> Neil
> ___
> 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 regarding offer-answer handling

[Paul Kyzivat]

Brett Tate wrote:
>>> I have some odd test scenario where initial call establishment
>> happens with
>>> recv only  / sendony.  After the establishment of the call  caller
>> reinvites
>>> with "0.0.0.0" and direction attribute recvonly. I understand that
>> this is a
>>> invalid case, but would like to get comments in this case how callee
>> should
>>> behave?. Does callee rejects the offer?
>> What makes you think this is an invalid case?
> 
> My assumption is that Suresh is interpreting the following RFC 3264 section 8 
> text normatively and still applicable when ("no longer recommended") 0.0.0.0 
> is used for hold:
> 
> "If the stream to be placed on hold was previously a sendrecv media stream, 
> it is placed on hold by marking it as sendonly.  If the stream to be placed 
> on hold was previously a recvonly media stream, it is placed on hold by 
> marking it inactive."
> 
> "RFC 2543 [10] specified that placing a user on hold was accomplished by 
> setting the connection address to 0.0.0.0.  Its usage for putting a call on 
> hold is no longer recommended, since it doesn't allow for RTCP to be used 
> with held streams, doesn't work with IPv6, and breaks with connection 
> oriented media."

Maybe that's his assumption. But
- the above is not normative
- we don't know that the UAC is "placing the user on hold".
   It may have some other motivation for doing this.
   Since its at the beginning of the call, I'm inclined to guess
   that it isn't hold as that is normally understood.

Its really not the job of the UAS to understand *why* this is happening. 
Its job is simply to respond in the best way it can given its own 
circumstances.

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

Re: [Sip-implementors] Question regarding offer-answer handling

[Paul Kyzivat]

Suresh Arunachalam wrote:
> Hello All,
> 
> I have some odd test scenario where initial call establishment happens with
> recv only  / sendony.  After the establishment of the call  caller reinvites
> with "0.0.0.0" and direction attribute recvonly. I understand that this is a
> invalid case, but would like to get comments in this case how callee should
> behave?. Does callee rejects the offer?

What makes you think this is an invalid case?

The behavior may seem odd/excessive, but there is nothing intrinsically 
*invalid* about it.

Of course the callee *may* reject the offer if it wishes. But if the 
desire is to maximize interoperability, then should accept the offer.

I would recommend that the callee respond with a compatible answer as 
close to what it would prefer as possible. Given the offer had recvonly, 
the only valid responses are sendonly or inactive. Since there is no 
address to send to, I think either would be ok. The address in the 
answer could either be a valid one, or 0.0.0.0, and again I think either 
would be acceptable. If you provide a valid address, then you *should* 
be prepared to receive RTCP, though its unlikely that the caller will be 
using it. I would be sympathetic to a device that didn't assign media 
resources in this case and so responded with 0.0.0.0.

Have you looked at

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

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

Re: [Sip-implementors] contact header scheme

[Paul Kyzivat]

Iñaki,

Iñaki Baz Castillo wrote:
> 2010/4/20 Brett Tate :
>> section 5.1.1.1:
>> "  If all the Contact header fields in a REGISTER request are SIPS, the
>>   UAC MUST use SIPS AORs in the From and To header fields in the
>>   REGISTER request.  If at least one of the Contact header fields is
>>   not SIPS (e.g., sip, mailto, tel, http, https), the UAC MUST use SIP
>>   AORs in the From and To header fields in the REGISTER request.
>> "
> 
> Is it a joke? or another hyper-exotic and unfeasible feature born in
> IETF? how is supposed that a Contact field in a REGISTER can be a
> "mailto" or "http"???

It is not a joke, though I have never heard of it being used yet.

Obviously such a contact cannot be used for transporting sip traffic. 
However it can potentially be used as an alternative means of reaching 
the AOR.

For instance, if a mailto: url were among the registered contacts, and 
none of the sip contacts was reachable, the proxy for the AOR could 
return a 3xx with the mailto contact. Then the caller could send an 
email with a message. This is potentially a voicemail mechanism that 
doesn't require a voicemail server.

Another possibility is a tel: URL.

Rather that considering it "hyper-exotic and unfeasible", you could just 
consider it "forward looking".

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

Re: [Sip-implementors] [Simple] Question on RFC 4662 - ResourceListSubscription

[Paul Kyzivat]

Avasarala Ranjit-A20990 wrote:
> It could be that they did not anticipate the buddy list to very large
> one.  

Or it could be that they expected that the implementors would support 
TCP, as 3261 requires them to do.

Thanks,
Paul

> Regards
> Ranjit
> 
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Vavilapalli Srikanth-A19563
> Sent: Friday, April 09, 2010 2:21 PM
> To: Pandurangan R S; sim...@ietf.org
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] [Simple] Question on RFC 4662 -
> ResourceListSubscription
> 
> There was also an example given in RFC 4662 in Section 6 at Page 20..
> 
> 3.   As is required by RFC 3265 [2], the RLS sends a NOTIFY immediately
> upon accepting the subscription.  In this example, we are assuming that
> the local RLS is also an authority for presence information for the
> users in the "vancouver.example.com" domain.  "*The NOTIFY
> contains an RLMI document describing the entire buddy list (initial
> notifies require full state)*", as well as presence information
> for the users about which it already knows.
> 
>
>  uri="sip:adam-frie...@pres.vancouver.example.com"
>  version="1" fullState="true">
>  Buddy List at COM
>  Liste der Freunde an COM
>  
>Bob Smith
>  cid="buz...@pres.vancouver.example.com"/>
>  
>  
>Dave Jones
>  cid="zvs...@pres.vancouver.example.com"/>
>  
>  
>Ed at NET
>  
>  
>My Friends at ORG
>Meine Freunde an ORG
>  
>
> 
> In the above example List "adam-budd...@pres.vancouver.example.com"
> contains members as
> sip:b...@vancouver.example.com,
> sip:d...@vancouver.example.com,
> sip:e...@dallas.example.net and
> sip:adam-frie...@stockholm.example.org
> 
> 
> Not sure why RFC mandates/recommends to keep the entire buddy list info
> in the first NOTIFY.. 
> 
>  
> 
> -Original Message-
> From: simple-boun...@ietf.org [mailto:simple-boun...@ietf.org] On Behalf
> Of Vavilapalli Srikanth-A19563
> Sent: Friday, April 09, 2010 12:38 PM
> To: Pandurangan R S; sim...@ietf.org
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 -
> ResourceList Subscription
> 
> Forwarding to SIMPLE mailing list... 
> 
> -Original Message-
> From: Pandurangan R S [mailto:pandurangan@gmail.com]
> Sent: Friday, April 09, 2010 12:07 PM
> To: Vavilapalli Srikanth-A19563
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List
> Subscription
> 
> RFC 4662 states
> 
>The third mandatory attribute is "fullState".  The "fullState"
>attribute indicates whether the NOTIFY message contains information
>for every resource in the list.  If it does, the value of the
>attribute is "true" (or "1"); otherwise, it is "false" (or "0").  The
>first NOTIFY sent in a subscription MUST contain full state, as must
>the first NOTIFY sent after receipt of a SUBSCRIBE request for the
>subscription.
> 
> Why is it a required that first NOTIFY contains information for every
> resource in the list? I believe it can have a initial information (which
> tells the subscriber to get rid of any old info) and then build upon the
> data using further NOTIFYs.
> 
> Any interop problems if the "fullState" flag is interpreted as
> "initialState" flag?
> 
> On Fri, Apr 9, 2010 at 10:48 AM, Vavilapalli Srikanth-A19563
>  wrote:
>> Hi
>>
>> I have a question related to first NOTIFY being generated for a 
>> Resource List Subscription assuming where the all the entities support
> 
>> only unreliable UDP transport and message size is limitied by path MTU
> 
>> size (because of for ex. No support for UDP fragmentation by the 
>> intermediate routers on that network)..
>>
>> As per RFC 4662, The first NOTIFY sent in a subscription MUST contain 
>> full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE
> 
>> request for the subscription. And the "fullState" attribute indicates 
>> that the NOTIFY message contains information for every resource in the
> 
>> list..
>>
>> Assuming a user has subscribed to his buddy list of 100 to 150 users 
>> and MTU size is defined as 1500 Bytes, How to fit the "full state"
>> information (which contains the RLMI with all the the user URIs with 
>> the state of subscription + ZERO or more presence states of each 
>> resource in the list) in the first NOTIFY sent towards subscrier?
>>
>> Are there any well defined schemes to split such a BIG NOTIFY in to 
>> multiple NOTIFYs without violating the above RFC 4662 requirement?
>>
>> Regards
>> Srikanth
>>
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs

Re: [Sip-implementors] Processing a 4xx, 5xx, 6xx response

[Paul Kyzivat]

Ayesha Shahab wrote:
> Hi,
> 
> For a non-established dialogs how do we have a 400 Bad Request response ?
> 
> The scenario is as follows
> 1. A sends an INVITE to B
> 2. A gets 100 trying response
> 3. A sends lot many OPTIONS towards B
> 4. B does not respond to the OPTIONS
> 5. B responds with 400 Bad Request for the INVITE
> 6. A receives a 400 terminate indication
> 7. ???

Based on the info above, there is no dialog - not even an early dialog.
(To have one A would have to receive a 1xx response (xx != 00) with a 
To-tag.)

So there is no dialog to deal with. You will complete the INVITE 
*transaction* by sending an ACK.

You didn't say how the OPTIONS requests were addressed. They couldn't 
have been in-dialog because there is no dialog for them to be in.

Each of the outstanding OPTIONS transactions must complete 
independently. You will retransmit each one according to the state 
machine, and if you never get a response each transaction will 
eventually time out.

Thanks,
Paul

> What should happen at Step7? Do we terminate all the transactions (INVITE
> and OPTIONS) and bring down the dialog?
> If we terminate all the transactions and bring down the dialog, we will then
> not receive a 408 Request Timeout response for the OPTIONS..
> 
> How should we handle a 4xx, 5xx , 6xx response for a non-established dialog?
> 
> /Ayesha
> ___
> 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] [gruu] "first-cseq" attribute of RFC5628!

[Paul Kyzivat]

Here is the long explanation:

There are two sources of temp gruu information to the UA:
- that which is returned in the response to REGISTER requests
- that which is returned in notifications by the reg event package

Seemingly you wouldn't need the reg event package for this - you can 
simply accumulate all (or as many as you want) of those temp gruus 
returned in register responses.

BUT, its possible for some of those to become invalid. Specifically, 
support it is almost time for you to refresh your registration, but that 
you turn out to be late. So your old registration expires, and with it 
all the assigned temp gruus. Then, almost immediately, the REGISTER you 
intended as a refresh arrives to the registrar, who treats it as a *new* 
registration. It then assigns and returns a new temp gruu.

Unfortunately you cannot tell that this has happened based on the 
response to the REGISTER. So you will treat this as just another temp 
gruu to be added to your pot.

The "first-cseq" rule provides a way for you to tell, via the next 
NOTIFY, that all your *old* temp gruus have become invalid.

Thanks,
Paul

hanifa.mohammed wrote:
> all,
> 
> Pl find the below snippet in RFC 5628!
>   *  It should remove any temporary GRUUs with a "callid" attribute
>  value different from that in the value of the "callid"
>  attribute of the , or with a "cseq" attribute with
>  value less than the value of the "first-cseq" attribute of the
>  .
> 
> It means that the Registrar shall invalidate the temporary GRUU, when a
> certain limit is reached. And, the limit shall be conveyed to UE using 
> reg-ev
> package. Is this true?
> 
> It contradicts the fact that RFC5627 mentions that the temporary
> GRUU is valid till the user deregister or registers with a different Call-Id 
> header.
> 
> What is the real need for "first-cseq" attribute in this RFC?
> 
> Best Regards,
> Mohammed Hanifa 
> 
> ___
> 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] GRUU: Why can temp-gruu be diferent for each registration refresh?

[Paul Kyzivat]

Iñaki Baz Castillo wrote:

> But if the algorithm for constructing temp gruus would be known then
> it would become a vulnerability :(

Security by obscurity is never a great choice.

Crypto techniques can largely avoid the vulnerability.

I thought this was discussed in the RFC. (But I'm too lazy to check 
right now.)

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

Re: [Sip-implementors] GRUU: Why can temp-gruu be diferent for each registration refresh?

[Paul Kyzivat]

Iñaki,

This is probably far from obvious.

The reason for creating new ones was because for anonymization purposes 
you probably don't want to keep using the same one. It would have been 
better to have an explicit mechanism to request when you want a new one, 
but that didn't fit into the model well. (There were a lot of needs to 
balance in doing this. The result is not very pretty.)

If you think about it for awhile, you will find that it is possible to 
come up with an algorithm for constructing temp gruus that doesn't 
require the registrar to keep permanent state for each one created. (Or 
course its also possible to create algorithms that *do* require state, 
but that is for you to decide.)

Thanks,
Paul

Iñaki Baz Castillo wrote:
> 2010/3/21 Iñaki Baz Castillo :
>> Hi, after reading the RFC 5627 I don't understand why the registrar
>> can create a new temp-gruu URI for each registration refresh.
>> If it does so, the registrar would end with a database full of temp-gruu 
>> URI's.
>>
>> From the point of view of a registrar implementing GRUU, is it posible
>> to mantain an unique temp-gruu for each registration instance (as it
>> occurs for the public-gruu?
>> It would make the implementation easier (by adding two columns
>> "temp_gruu" and "public_gruu" in the location database table).
>>
>> Do I miss something? Also, the example in section 9 of RFC 5627 shows
>> the same temp-gruu for two different registration from same UA
>> instance (as it crashed and generates a new registration with
>> different Call-ID after rebooting).
> 
> 
> This is the exact point I cannot understand in RFC 5627:
> 
> -
> 3.2.  Obtaining a GRUU
> 
>When a user agent refreshes this registration prior to its
>expiration, the registrar will return back the same public GRUU, but
>will create a new temporary GRUU.  Despite the fact that each refresh
>provides the UA with a new temporary GRUU, all of the temporary GRUUs
>learned from previous REGISTER responses during the lifetime of a
>contact remain valid as long as (1) a contact with that instance ID
>remains registered, and (2) the UA doesn't change the Call-ID in its
>REGISTER request compared to previous ones for the same reg-id
> -
> 
> 
> By following this specification, if a phone is registered for one day
> by refreshing its registration hourly (same Call-ID), then the
> registrar would have to store 24 temp-gruu values for same
> registration. How could it make sense?
> 
> So my question is: is it legal if the registrar mantains an *unique*
> temp-gruu per registration (according to AoR and sip.instance)?
> 
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] Managing sip Session progress 183.

[Paul Kyzivat]

I agree that it is better to return a 180 if you know that alerting is 
happening. Unfortunately, the UAS doesn't always know that. Gateways in 
particular may not know.

So the UAC has to be prepared to cope if the 180 doesn't arrive.

Thanks,
Paul

Olle E. Johansson wrote:
> 20 mar 2010 kl. 16.40 skrev Iñaki Baz Castillo:
> 
>> 2010/3/20 Olle E. Johansson :
>>
 For example, some TDM nodes fake the ringing and generate real audio.
 When such TDM signaling arrives to a SIP-PSTN gateway, it must
 generate a 183 with SDP :(
>>> NO, IT can generate 180 with SDP as default...
>> IMHO there is no difference at all between a 180 and 183 both with SDP.
> "180 ringing" is a state that I can relay to other protocols - we know that 
> there's
> something out there that is in fact alerting the callee. 183 can be anything,
> normally translated as PROGRESS. In many apps, the ringing state is 
> very important and it will be missed if we get no 180.
> 
>> Does a 180 with SDP mean that the UAC could choose to render the real
>> audio or internal artificial ringing?
> Remember that the rendering might be something very different than audio.
> 
>> If so, how the UAC would know if the received early media is just a
>> real ringing or a voice message "you have no credit to call, please
>> pay or die" ?
> Well, in my head the 180 with SDP means I'll get a ring signal in audio.
> 
> 183 with SDP is something I would like to be limited to operator messages 
> before an error code in the implementations, or just an informationial 
> message before proceeding with ringing ("You need to refill your account 
> soon"). Today, it's very often used for ringing and I can't determine if we 
> actually have someone that is alerted on the other end.
> 
> Especially with gateways to deaf people, it is very important to get an alert 
> confirmation so that we can render the ringing in some way that works and we 
> can move to a state where we are more prepared to activate a translator 
> service. Sending 183 with audio doesn't help at all.
> 
> /O
> ___
> 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] Does SIP/SDP allow one-way RTP?

[Paul Kyzivat]

Iñaki Baz Castillo wrote:
> 2010/3/20 Schwarz Albrecht :
>> It's amazing that such a fundamental session configuration topic is not 
>> really well specified (explicitly, detailed, unambiguous) in RFCs 3261 & 
>> 3264. Just wondering ...
> 
> I agree. When such kind of issues occur it means that interoperability
> is difficult as different implementors would not interpret the same
> (as the specification is not detailed and clear).
> 
> This is: when a question requires a long thread to be "resolved" with
> the participation of varios SIP experts, and there is no full
> agreement between them, then we have a problem and perhaps such
> specification should be improved or redesigned (IMHO).

I agree. In this case I find it a bit surprising that there are 
questions. I thought this stuff was clear.

But what's clear to those of us that have been working with this stuff 
for a long time isn't always clear to newcomers. Thats one of the reason 
we keep having various clarification documents.

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

Re: [Sip-implementors] Managing sip Session progress 183.

[Paul Kyzivat]

Olle E. Johansson wrote:
> 20 mar 2010 kl. 15.50 skrev Iñaki Baz Castillo:
> 
>> 2010/3/20 Pranab Bohra :
>>> As per section 2.1 of rfc 3666, the softphone should open the rtp port
>>> to receive early media when the gateway responds with 183 +  SDP.
>> The problem is that some servers/gateways send first a 183 with SDP.
>> The UAC receives the early media. But after a second (or less) the
>> server sends a 180 and *stops* the RTP.
> I guess that you mean an 180 without SDP.

Receiving SDP has nothing to do with opening your audio port.
The UAS could be sending audio even though it has not yet sent an answer.

>> If the UAC chooses to render the real audio (183) rather than the
>> artificial ringing (180) then there will be no audio anymore (until
>> the 200 arrive of course).
>> This occurs with some phones and some servers.
>>
> Yep.
> 
> /O
> ___
> 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] Managing sip Session progress 183.

[Paul Kyzivat]

Iñaki Baz Castillo wrote:
> 2010/3/20 Pranab Bohra :
>> As per section 2.1 of rfc 3666, the softphone should open the rtp port
>> to receive early media when the gateway responds with 183 +  SDP.
> 
> The problem is that some servers/gateways send first a 183 with SDP.
> The UAC receives the early media. But after a second (or less) the
> server sends a 180 and *stops* the RTP.
> If the UAC chooses to render the real audio (183) rather than the
> artificial ringing (180) then there will be no audio anymore (until
> the 200 arrive of course).
> This occurs with some phones and some servers.

IMO you should treat it this way:

- if you are receiving audio, render it
- if you are not receiving audio, and you have received a 180
   then generate ringback.

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: section 12.2.1.2 VS section 11

[Paul Kyzivat]

Actually, Brett gave the best answer.

The lack of response to OPTIONS should not have caused a presumption 
that the dialog, or the invite dialog usage, has failed. Lacking some 
other failure, the RTP should have continued to flow and the call should 
have stayed up.

Once the RTP stopped flowing, for whatever reason, if the recipient of 
that RTP decides that it no longer values the call and wants to end it, 
then it is obligated to send a BYE.

Thanks,
Paul

Iñaki Baz Castillo wrote:
> 2010/3/19 WORLEY, DALE R (DALE) :
>> The basic answer to your question is "yes".  In general, in any dialog or 
>> usage, if a UA decides that it is terminated, for any reason than a message 
>> from the remote UA that states that the dialog/usage is termianted, the UA 
>> should send an explicit termiantion message.
>>
>> In this case, if a UA receives a 408 response to an OPTIONS and decides that 
>> it must terminate the dialog, since it does not know that the remote UA 
>> knows that the dialog has been terminated, it should send a BYE.  Of course, 
>> there is no guarantee that the remote UA will see the BYE.
>>
>> Of course, the CDRs at the two UAs will likely be different, but in the face 
>> of network outages, the two UAs will not always agree on the state of the 
>> dialog.
> 
> 
> Thanks a lot.
> 
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] [gruu] First temporary GRUU

[Paul Kyzivat]

KUMARAVEL ANAND-MWCH34 wrote:
>  
> Hanifa,
>   As per RFC 5627,section 3.2, all of the temporary GRUUs learned
> from REGISTER responses of a contact remain valid as long a contact with
> that instance ID remains registered and the UA doesn't change the
> Call-ID in its REGISTER request compared to previous ones for the same
> reg-id.
> 
> So you can use the first temp-gruu as long as the conditions above are
> satisfied.

You can do that if you wish. It certainly is simpler.

In any case, you only need to remember the ones you use, or may want to use.

Beware that if you use the same one for multiple calls then you are 
compromising your privacy because those can be correlated to recognize 
they are from the same UA.

Thanks,
Paul

> Thanks
> Anand.
> 
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> hanifa.mohammed
> Sent: Friday, March 19, 2010 3:32 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] [gruu] First temporary GRUU
> 
> Hi,
> In GRUU, for every REGISTER, the Registrar gives a different
> temp-gruu value. i.e. even for each refresh, a temp gruu is given.
> Registrar guarantees that all temp gruu's are valid till the user
> deregisters or change-in-callid value.
> 
> My question is that whether the first temp-gruu shall be used for
> all dialogs (with privacy), though a new temp-gruu is given for each
> refresh REGISTER. 
> 
> Programmatically, I have some issue updating the temp-gruu value
> everytime for refresh REGISTER.
> Pl share your thoughts.
> 
> Best Regards,
> Mohammed Hanifa
> ___
> 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] Does SIP/SDP allow one-way RTP?

[Paul Kyzivat]

Iñaki,

Note that specifying a=recvonly gives a receive the video without 
sending any. But in that case you are still expected to send rtcp.
If you want to avoid that too, then you should specify c=0.0.0.0.

Thanks,
Paul

Iñaki Baz Castillo wrote:
> 2010/3/19  :
>> Hi,
>>
>> Yes, Bob can accept, but to decode Video Bob system must be capable of 
>> decoding the codec offered in Video SDP.
> 
> This is common. A softphone is usually able to render an incoming
> video stream, but a webcam is required to sent video :)
> 
> 
>> He can answer with Send Recive for audio and Receive only for Video.
>>
>> As per offer answer RFC, an offer with "sendrecv" media stream can be 
>> answered with "recvonly", "sendonly" ,"inactive"
>> Based on far ends capability.
> 
> Ok, I understand now, thanks a lot.
> 
> 
> 
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: [Sip-implementors] GRUU - SIP extension Basic questions

[Paul Kyzivat]

Premalatha Kuppan wrote:
> Hi,
> 
> I have some basic question on GRUU (sip extension - GRUU RFC 5627 )

I think that most of your questions are not specifically related to gruu.

> 1. Can i have multiple devices like mobile phone, laptop etc with sip client
> on it and use both the device during the same call ?

You may have multiple devices registered with the same AoR (address of 
record - uri).

Having them all ring when the AoR is called is straightforward.
Having them all participate in the call is complicated.
It that is what you care about its a long discussion.

> During registration, REGISTER request is going to be from one device say
> mobile, then how other devices is registered ? Do i need to have GRUU
> support in all devices?

If they are independent devices then typically they will each register 
independently.

You don't need gruu support (by anything) for any of this to work.

> 2. Does the server/Registrar should also support GRUU extension ?

Most of the gruu mechanism requires support by both the registering 
device and the registrar.

With multiple devices, it would be possible for some to support gruu and 
others not to, all registered to the same AoR. (But the registrar would 
have to support it.)

> 3. Should end user need to support GRUU, say for example,
> User A : GRUU support (different devices: mobile phone, laptop)
> User B : no GRUU support

Generally the two ends of a call can independently support or not 
support gruu. In many cases one end can get benefit from its gruu 
support even if the other end does not support and is not aware of gruu.

You can think of gruu as simply being a remedy for limitations in 
implementations. Technically the Contact URI provided by a UA in a call 
is supposed to be globally routable. Gruu helps UAs that don't otherwise 
have a globally routable URI to put in their Contact. So long as the 
other party acts as if the Contact URI it provides is globally routable, 
it need not know anything about gruu, and features should just work.

However, some UAs have been implemented on the assumption that the 
Contact they receive from the other party is *not* globally routable. 
They then use odd ways to implement features. With such a UA, being 
aware of gruu, and noticing that the received contact is a gruu, can 
enable them to implement features in a better way.

> If User B makes a call to User A, will both my device Mobile phone and
> laptop with sip client gets the alert ?

This has nothing to do with gruu.
Assuming both devices were registered, it is up to the proxy/registrar 
to decide how to deliver the call. It may choose to route the call to 
one or the other, or fork it to both so they both ring. It may try one 
and then the other.

> I assume User B needn't have to have
> GRUU support in to establish the call in above scenario.

Right.

Good Luck,
Paul

> I appreciate some valuable input.
> 
> Thanks,
> Premalatha
> ___
> 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