headers
shweta kavishwar | 3 Jan 2008 05:47
Picon
Gravatar

4566 SDP grammar for phone-line

Hi,

Section 5.6 of RFC 4566 says:

" Phone numbers SHOULD be given in the form of an international public
  telecommunication number (see ITU-T Recommendation E.164) preceded by
  a "+".  Spaces and hyphens may be used to split up a phone field to
  aid readability if desired.  For example:

   p=+1 617 555-6011 "

However, according to the grammar specified in the RFC, the "+" is made
optional (refer quoted text below):

   ; sub-rules of 'p='
   phone-number =        phone *SP "(" 1*email-safe ")" /
                         1*email-safe "<" phone ">" /
                         phone

   phone =               ["+"] DIGIT 1*(SP / "-" / DIGIT)

The earlier implementation mandated the "+" for phone. The grammar is
therefore not in sync with the descriptive
text. How do i interpret this?

Rgds,
Shweta.
Permalink | Reply | 1 comment |
headers
Paul Kyzivat | 3 Jan 2008 06:28
Picon
Favicon

Re: 4566 SDP grammar for phone-line

Why does it matter? AFAIK the phone number in SDP is simply for 
documentation, not for automated usage. This is especially the case if 
the SDP is being used with SIP.

	Paul

shweta kavishwar wrote:
> Hi,
> 
> Section 5.6 of RFC 4566 says:
> 
> " Phone numbers SHOULD be given in the form of an international public
>   telecommunication number (see ITU-T Recommendation E.164) preceded by
>   a "+".  Spaces and hyphens may be used to split up a phone field to
>   aid readability if desired.  For example:
> 
>    p=+1 617 555-6011 "
> 
> However, according to the grammar specified in the RFC, the "+" is made
> optional (refer quoted text below):
> 
>    ; sub-rules of 'p='
>    phone-number =        phone *SP "(" 1*email-safe ")" /
>                          1*email-safe "<" phone ">" /
>                          phone
> 
>    phone =               ["+"] DIGIT 1*(SP / "-" / DIGIT)
> 
> The earlier implementation mandated the "+" for phone. The grammar is
> therefore not in sync with the descriptive
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aneesh Naik | 3 Jan 2008 10:13
Picon

CSeq header with overlarge value.

Hi,

According to RFC 4475 - Torture Test Messages: Section 3.1.2.4.  Request
Scalar Fields with Overlarge Values.
If the CSeq value is in error (ie. > 2**32 -1) in Request message then the
entity should respond with 400 bad request due to CSeq error.

What should be the CSeq value in the 400 bad request?
As the value received in the request is already in error, we cannot respond
with that value.

So will it be correct to set CSeq as "0" in the response message as we wont
be able to set the value received in the request message?
Or what value can we set for CSeq in the response message?

--

-- 
Aneesh
Permalink | Reply | 1 comment |
headers
Sigrid Thijs | 3 Jan 2008 14:56

merged request with to tag

Hi,

when a UA receives a PRACK request (with To-tag) that does not match an 
ongoing transaction (different Via headers), but the Request-URI, 
To-tag, From-tag, Call-ID and CSeq exactly match an ongoing transaction, 
what would be the appropriate behavior of the UAS?
- Send a 482 Loop Detected?
- Discard the request?
- Treat as a new request?

kind regards,

Sigrid Thijs
Permalink | Reply | 3 comments |
headers
Robert Sparks | 3 Jan 2008 15:48
Favicon

Re: CSeq header with overlarge value.

You would be better off to return whatever CSeq showed up. The  
previous hop that sent it was ok
with it in the request, and you really want it to believe this  
response is to this request so it stops retransmitting.

The same is true if any of the other required things are too broken  
to process - if there's enough there to sensibly
make a response, responding with what you received, even though it's  
invalid, is more likely to make the other
end do the right thing than not.

RjS

On Jan 3, 2008, at 3:13 AM, Aneesh Naik wrote:

> Hi,
>
> According to RFC 4475 - Torture Test Messages: Section 3.1.2.4.   
> Request
> Scalar Fields with Overlarge Values.
> If the CSeq value is in error (ie. > 2**32 -1) in Request message  
> then the
> entity should respond with 400 bad request due to CSeq error.
>
> What should be the CSeq value in the 400 bad request?
> As the value received in the request is already in error, we cannot  
> respond
> with that value.
>
> So will it be correct to set CSeq as "0" in the response message as
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Sparks | 3 Jan 2008 15:54
Favicon

Re: merged request with to tag

Unless I misunderstand your question, you're describing how PRACKs  
are supposed to arrive.
A PRACK has its own transaction - it will have different Via headers  
than anything you've seen in,
for example, the associated INVITE.

RjS

On Jan 3, 2008, at 7:56 AM, Sigrid Thijs wrote:

> Hi,
>
> when a UA receives a PRACK request (with To-tag) that does not  
> match an
> ongoing transaction (different Via headers), but the Request-URI,
> To-tag, From-tag, Call-ID and CSeq exactly match an ongoing  
> transaction,
> what would be the appropriate behavior of the UAS?
> - Send a 482 Loop Detected?
> - Discard the request?
> - Treat as a new request?
>
> kind regards,
>
> Sigrid Thijs
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors <at> lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sigrid Thijs | 3 Jan 2008 16:11

Re: merged request with to tag

Robert Sparks wrote:
> Unless I misunderstand your question, you're describing how PRACKs are 
> supposed to arrive.
> A PRACK has its own transaction - it will have different Via headers 
> than anything you've seen in,
> for example, the associated INVITE.
> 

Sorry for the confusion, but I meant the arrival of a second PRACK, with 
only the Via headers different from the first one. If the PRACK would 
not contain the To-tag, our application would treat it as a merged 
request, according to section 8.2.2.2 of RFC 3261:

    If the request has no tag in the To header field, the UAS core MUST
    check the request against ongoing transactions.  If the From tag,
    Call-ID, and CSeq exactly match those associated with an ongoing
    transaction, but the request does not match that transaction (based
    on the matching rules in Section 17.2.3), the UAS core SHOULD
    generate a 482 (Loop Detected) response and pass it to the server
    transaction.

I'm wondering what would be the appropriate response in this case?

kind regards,

Sigrid Thijs

> 
> 
> On Jan 3, 2008, at 7:56 AM, Sigrid Thijs wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Sparks | 3 Jan 2008 16:21
Favicon

Re: merged request with to tag

Ok - I understand better now.

I think something upstream from you has broken protocol to deliver  
such a second PRACK to you.
PRACKs by definition can't fork due to retargetting. The only fork- 
like case that might lead to a legitimate
merge would be failover to other SRV records during the transaction -  
is that happening in your scenario?

Its not immediately obvious what to send. My knee-jerk reaction is to  
send a 400 (does 3262 say anything about
what to do if the peer doesn't increase RSeq?). But its probably  
worth poking at the conditions you're seeing this under.
Is the thing sending the PRACK messing up, or is it an intermediary?  
(Are there proxies involved and if so is this a retransmission
from the other endpoints Point-of-View that the proxies are  
mishandling?)

RjS

On Jan 3, 2008, at 9:11 AM, Sigrid Thijs wrote:

> Robert Sparks wrote:
>> Unless I misunderstand your question, you're describing how PRACKs  
>> are supposed to arrive.
>> A PRACK has its own transaction - it will have different Via  
>> headers than anything you've seen in,
>> for example, the associated INVITE.
>
> Sorry for the confusion, but I meant the arrival of a second PRACK,
(Continue reading)

Permalink | Reply | 0 comments |
headers
라스토기 | 4 Jan 2008 02:08

Re: merged request with to tag

Hi,
PRAK is new transaction hence, Cseq would be increment from previous transaction, so it is not possible
that UAS receives PRACK with same CSeq of previous transaction. But if UAC is malfunctioning with this
behavior then UAS should reject this message with 'Loop detected'.

Vipul Rastogi
Engineer, Business Management Team
Telecommunication Network Business
Samsung Electronics CO, LTD
Suwon P.O.BOX 105, 416
Korea 442-600
MO 010-9530-0354
----- Original Message ----- 
From: "Sigrid Thijs" <sigrid.thijs <at> androme.com>
To: "Sip-Implementors" <sip-implementors <at> lists.cs.columbia.edu>
Sent: Friday, January 04, 2008 12:11 AM
Subject: Re: [Sip-implementors] merged request with to tag

> Robert Sparks wrote:
>> Unless I misunderstand your question, you're describing how PRACKs are 
>> supposed to arrive.
>> A PRACK has its own transaction - it will have different Via headers 
>> than anything you've seen in,
>> for example, the associated INVITE.
>> 
> 
> Sorry for the confusion, but I meant the arrival of a second PRACK, with 
> only the Via headers different from the first one. If the PRACK would 
> not contain the To-tag, our application would treat it as a merged 
> request, according to section 8.2.2.2 of RFC 3261:
(Continue reading)

Permalink | Reply | 0 comments |
headers
JEEVANANDHAM KARTHIC KUMAR | 4 Jan 2008 08:17
Favicon

Reg: The Offer/Answer Model and PRACK

Hello All,

Could you please clarify my doubts :

According to the RFC3262 section 5: The Offer/Answer Model and PRACK

It defines that,
"If the UAC receives a reliable provisional response with an offer
   (this would occur if the UAC sent an INVITE without an offer, in
   which case the first reliable provisional response will contain the
   offer), it MUST generate an answer in the PRACK."

If the case received OFFER( media parameters ) is not acceptable by UAC.
How to reject the OFFER?
How to send PRACK message with ANSWER (???) or PRACK without SDP?

 
Regards,
Karthic kumar J
Permalink | Reply | 2 comments |

Gmane