Paul Kyzivat | 1 Sep 01:05 2009
Picon

Re: Question on multiple INFO messages


Yong Xin wrote:
> Hi, 
>  
> The RFC3261 is clear that UA can not send a re-INVITE when another
> INVITE is pending. However, for non-INVITE request (e.g.: INFO), I was
> not able to find any restriction like this. So I assume this is allowed.
>  
> However, sending another INFO before the previous one has been answered
> can cause problem when UDP packet is deliveried out-of-order. Here is an
> example:
>  
> - INFO (cseq=1) is lost due to network issue
> - INFO (cseq=2) is received and processed by the server
> - retranmission of INFO (cseq=1) arrives at server which replies with
> 500 error, because the cseq number is lower than the last cseq number on
> the dialog 
>  
> I'm wondering what is the right solution for this:
>  
> 1) Should we switch to use TCP as the transport protocol so that the
> order of the packet delivery is guaranteed?

Switching to TCP *won't* guarantee the order of delivery if there are 
any intermediate nodes in the path.

> 2) Should UAC send INFO messages in sequence (i.e.: not start a new one
> until previous one is final responded)?

I haven't seen this discussed with respect to INFO, but issues are much 
(Continue reading)

krishna chaitanya | 1 Sep 10:34 2009
Picon

Implicit de-registration failure

Hi All,

I have question regarding implicit de-registration.

2 IMPUs  belonging to same IRS( Implicit registration set) are registered from two end points.
when first IMPU is registered all the IMPU's belonging to IRS are
implcitly registered. and then the second IMPU is involved in a active
session and finally when the first IMPU is de-registered then the second IMPU
is still registered and the is still ongoing without any call release.

Observation 1: In 200 OK message for the second register request I see 2 contact headers belonging to 2 IMPU's.

Observation 2:  when the first IMPU is de-registered from one end point. then i see a 200OK for that
de-register message along with the contact header related to the second IMPU.

Here the implicit de-registration is not happening and as per 3GPP 24228 5.2.1a
When one of the Public User Identities within the set is de-registered, all 
Public User Identities that have been implicitly registered are de-registered at 
the same time.

But In this case below here is what happening due to the same 3GPP 24228 5.2.1a para

Registration and de-registration always relates to a particular contact address 
and a particular Private User Identity. A Public user identity that has been 
registered (including when implicitly registered) with different contact 
addresses remains registered in relation to those contact 
addresses that have not 
been de-registered.

So when first IMPU is registered all the IMPU's belonging to IRS are implcitly registerd. when the second
(Continue reading)

Paul Kyzivat | 1 Sep 17:18 2009
Picon

Re: Implicit de-registration failure


krishna chaitanya wrote:
> Hi All,
> 
> I have question regarding implicit de-registration.

This isn't the ideal place to ask this question.
Implicit registration is not part of any ietf standard,
its a creation of IMS.

> 2 IMPUs  belonging to same IRS( Implicit registration set) are registered from two end points.

I'm not certain I understand. Is the following what you mean?

- IMPU is a UA? Or an AOR? Since you mention end points too, I'll assume
   an IMPU is an AOR.

- AORs X, Y, and Z are part of the same IRS, so that
   if X is registered then Y and Z are implicitly registered;
   if Y is registered then X and Z are implicitly registered.

- You have one UA that registers X

- You have another UA that also registers X (or Y or Z)

> when first IMPU is registered all the IMPU's belonging to IRS are
> implcitly registered.

ok.  So AOR X was registered by UA-A, and Y and Z are also implicitly 
registered to UA-A.
(Continue reading)

Iñaki Baz Castillo | 1 Sep 18:53 2009
Picon

Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation

2009/8/31 Francois Audet <audet <at> nortel.com>:
> I would tend to disagree that a policy of "Use UDP preferably
> and switch to TCP if message is too big" is a good policy. Especially
> considering that you'd have to keep the TCP connection alive anyways.
>
> I believe that always using the TCP connection in this case would
> make more sense.

I agree totally.
If a client uses UDP then it uses UDP and the same for TCP, but don't
mix please, as mixing both protocols in the same client is an exotic
and idealistic concept just feasible in a "ideal" world (the world
described in RFC 3261).

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Schwarz Albrecht | 1 Sep 23:02 2009
Picon

Re: [Sip-implementors] overloading static RTP payload types with dynamic payload types

Amy,
you shouldn't look in SIP specs, rather to RTP itself.
See RFC 3550, in particular § 13 on "RTP Profiles and Payload Format Specifications".

Thus, the usage (binding) of PT values should be defined by an RTP profile.
And your "m=" line refers to the RTP "AVP" Profile (= RFC 3551).

Your question is thus related to RFC 3551 in my opinion.
-Albrecht 

> -----Original Message-----
> From: sip-implementors-bounces <at> lists.cs.columbia.edu 
> [mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On 
> Behalf Of Vikram Chhibber
> Sent: Montag, 24. August 2009 20:22
> To: Amy Hwang
> Cc: sip-implementors <at> lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] overloading static RTP 
> payload types withdynamic payload types
> 
> IMO, it is legal to define a static payload type as dynamic 
> too. The RTP payload type must be 97 for RTP that is being 
> sent out. The SDP answer might have a changed value of the 
> payload type. For more details please refer to Section 5.1 of 
> RFC 3264. Here is an excerpt:
> 
> For recvonly RTP streams, the payload type numbers indicate the value
>    of the payload type field in RTP packets the offerer is 
> expecting to
>    receive for that codec.  For sendonly RTP streams, the payload type
(Continue reading)

Dushyant Dhalia | 2 Sep 08:10 2009

Re: Implicit de-registration failure

Please see my response inline. I suppose this is not the correct forum 
for IMS questions.

Regards,
Dushyant P S Dhalia,
Rancore Technologies Pvt. Ltd.,
Gurgaon (INDIA)

krishna chaitanya wrote:
> Hi All,
>
> I have question regarding implicit de-registration
> 2 IMPUs  belonging to same IRS( Implicit registration set) are registered from two end points.
>   
I assume there are two IMPUs IMPU1, IMPU2 which are explicitly 
registered from UA1 and UA2 which have IMPI1, IMPI2 and contact1, 
contact2. Both the AoR i.e. IMPU1 and IMPU2 are in IRS.
> when first IMPU is registered all the IMPU's belonging to IRS are
> implcitly registered. 
Correct.
> and then the second IMPU is involved in a active
> session 
Does that mean UA2 with IMPU2 involved in session?
> and finally when the first IMPU is de-registered then the second IMPU
> is still registered and the is still ongoing without any call release.
>   
Does that mean UA1 is deregistering IMPU1? If it's so then it's as per 
specs?
> Observation 1: In 200 OK message for the second register request I see 2 contact headers belonging to 2 IMPU's.
> Observation 2:  when the first IMPU is de-registered from one end point. then i see a 200OK for that
(Continue reading)

Nils Ohlmeier | 2 Sep 09:52 2009

Re: Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation

Am 31.08.09 19:11, schrieb Francois Audet:
> I would tend to disagree that a policy of "Use UDP preferably
> and switch to TCP if message is too big" is a good policy. Especially
> considering that you'd have to keep the TCP connection alive anyways.
>
> I believe that always using the TCP connection in this case would
> make more sense.
>
> But it's definitively legal.

I totally agree with this.

But from several years attending SIPit's I would highly recommend you to 
NOT mix UDP and TCP. From time to time I had already interoperability 
issues when my proxy did for example UDP to TCP conversion (and back). 
If you are talking/thinking about an UA implementation which mixes UDP 
and TCP on the first hop already I would anticipate lots of 
interoperability issues down the road. You should at least attend a 
SIPit to check how other proxy and UA implementations react on this. In 
the end any benefits which you might get from this design decision might 
be easily eaten up by the support efforts later.

Best regards
   Nils Ohlmeier
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

(Continue reading)

raikkme rrrrr | 2 Sep 12:38 2009

183 Session Progress after 180 Ringing (with Same To Tag)

Hi all,

Is it possible to receive 183 Session Progress after 180 Ringing (with Same
To Tag)?
If so, under what cases?

Thanks,
raik
Robert Sparks | 2 Sep 16:18 2009

Registrations for SIPit25 closes in 2 days

Registration for SIPit 25 closes this Friday.

If you plan to attend and haven't registered, please do so now.

Information about the event and a link to the registration website can  
be found at http://www.sipit.net

RjS
Brett Tate | 2 Sep 16:30 2009

Re: 183 Session Progress after 180 Ringing (with Same To Tag)

> Is it possible to receive 183 Session Progress after 
> 180 Ringing (with Same To Tag)?

Yes.

> If so, under what cases?

Whenever the UAS wants to send 183 after 180.


Gmane