headers
bindukumari.r | 1 Mar 2011 06:08
Favicon

Query on precondition

Hi,
    If a endpoint-1 offers precondition as follows :

    supported:precondition, 100rel
    SDP Parameters
    a=curr:qos local none
    a=curr:qos remote none
    a=des:qos none local sendrecv
    a=des:qos none remote sendrecv

    If for the endpoint-2 the precondition support is mandatory, then
what should be the answer for this offer
    1) Should the call fail (i.e error response must be sent?)
    2) Or according to the following text of RFC 3312
            Note that the rules above apply to the desired strength-tag
"none" as
            well. This way, a user agent that supports quality of
service but
            does not intend to use them, adds desired status lines with
the
            strength-tag "none". Since this tag can be upgraded in the
answer,
            as described in Section 5.2, the answerer can request
quality of
            service reservation without a need of another offer/answer
exchange.
        Can the answer be the following?
            a=curr:qos local sendrecv
            a=curr:qos remote none
            a=des:qos mandatory local sendrecv
(Continue reading)

Permalink | Reply | 0 comments |
headers
bindukumari.r | 1 Mar 2011 08:32
Favicon

Query related to precondition scenario.

Hi,
    Please clarify the below mentioned scenario wrt precondition- 

    If Endpoint-1 sends Offer with following precondition attributes
with Require header containing precondition and 100rel - 
    (Endpoint-1 has precondition support as mandatory)
    Offer
    a=curr:qos local sendrecv
    a=curr:qos remote sendrecv
    a=des:qos mandatory local sendrecv
    a=des:qos mandatory remote sendrecv

    If the other endpoint sends the answer as follows with supported
header containing precondition and 100rel - 
    (Endpoint-2 has precondition support as optional)
    Answer
    a=curr:qos local none
    a=curr:qos remote sendrecv
    a=des:qos mandatory local sendrecv
    a=des:qos mandatory local sendrecv

    In this case 
    1) Since the Callee has not reserved the resources (indicated by
a=curr:qos local none ), Should the Caller reject the call ?
    2) If not, should RTP flow between the Caller and Callee ?

Thanks in advance.

Regards 
Bindu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iñaki Baz Castillo | 1 Mar 2011 08:59
Gravatar

Re: NAT traversal failing

Please, reply to the maillist.

2011/3/1 anand madhab <anandmadhab <at> gmail.com>:
> I accept this, but i wanted to know while ACK will be going
> directly from one end to other end then how to bypass NAT, bcz NAT
> isn't allowing direct ACK from one user to other user.

Maybe if the NAT router of the UAS implements some kind of specific
NAT and the UAC uses STUN then the ACK could arrive. However I don't
think this is feasible in common scenarios.

--

-- 
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
Permalink | Reply | 3 comments |
headers
Nikos Leontsinis | 1 Mar 2011 09:06
Picon

ascii encoding

I don't know if anyone has come across the following problem:
I am trying to send to a customer the sip2sip call in the format
6300#30xxxxx and the call fails.
I am reading the rfc 2396 paragrapth 2.4.3:

The control characters in the US-ASCII coded character set are not
   used within a URI, both because they are non-printable and because
   they are likely to be misinterpreted by some control mechanisms.

   control     = <US-ASCII coded characters 00-1F and 7F hexadecimal>

   The space character is excluded because significant spaces may
   disappear and insignificant spaces may be introduced when URI are
   transcribed or typeset or subjected to the treatment of word-
   processing programs.  Whitespace is also used to delimit URI in many
   contexts.

   space       = <US-ASCII coded character 20 hexadecimal>

   The angle-bracket "<" and ">" and double-quote (") characters are
   excluded because they are often used as the delimiters around URI in
   text documents and protocol fields.  The character "#" is excluded
   because it is used to delimit a URI from a fragment identifier in URI
   references (Section 4). The percent character "%" is excluded because
   it is used for the encoding of escaped characters.

   delims      = "<" | ">" | "#" | "%" | <">

   Other characters are excluded because gateways and other transport
   agents are known to sometimes modify such characters, or they are
(Continue reading)

Permalink | Reply | 7 comments |
headers
Iñaki Baz Castillo | 1 Mar 2011 11:18
Gravatar

Re: ascii encoding

2011/3/1 Nikos Leontsinis <leontsinis <at> gmail.com>:
> 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
<ibc <at> aliax.net>

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Permalink | Reply | 5 comments |
headers
Peter Krebs | 1 Mar 2011 11:28
Picon

481/408 response on Re-INVITE

Good morning,

I have a question regarding the handling of 481/408 responses on Re-INVITEs:
RFC3261, sec. 14.1 states that upon receipt of one of these responses (or on
timeout of the re-invite transaction) the dialog in which the Re-INVITE has
been sent must be terminated by the UAC. This is further explained in sec.
12.2.1.2 where it is stated that a BYE is sent to terminate the dialog.
However, since 481 implies that the UAS does not possess information on the
dialog referenced in the Re-INVITE and 408/timeout means the Re-INVITE was
not even properly processed, sending a BYE which references the exact same
dialog does not make any sense to me.
Did I just misread the RFC and the dialog can just be cleaned up locally or
is the UAC nevertheless supposed to send a BYE, cleaning up the dialog when
the BYE transaction finally terminates? I also looked up RFC5407 where
example 3.2.2 shows that no BYE is sent after receiving 481 (however, in
that particular case, the peer has sent a BYE before, but just suppose the
BYE got lost in the network).

Thanks in advance for any answers,

Peter
Permalink | Reply | 3 comments |
headers
Iñaki Baz Castillo | 1 Mar 2011 11:52
Gravatar

Re: NAT traversal failing

2011/3/1 anand madhab <anandmadhab <at> gmail.com>:
> In case of symmetric NAT it is not able to receice direct ACK... what
> we can do to this ?

Probably nothing. Maybe a hard redirection of the port 5060, but that
just would work for a single phone behind the router.

--

-- 
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
Permalink | Reply | 0 comments |
headers
Nikos Leontsinis | 1 Mar 2011 12:03
Picon

Re: ascii encoding

I am not sure if implementors are obliged to honour this request.

On 1 March 2011 12:18, Iñaki Baz Castillo <ibc <at> aliax.net> wrote:
> 2011/3/1 Nikos Leontsinis <leontsinis <at> gmail.com>:
>> 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
> <ibc <at> aliax.net>
>

--

-- 
Nikos Leontsinis
GSM: +306974477561
office:2103301193
ICQ Number:  201-100-938
msn: leontsinis <at> gmail.com
skype: leontsinis2
Permalink | Reply | 4 comments |
headers
Iñaki Baz Castillo | 1 Mar 2011 12:09
Gravatar

Re: ascii encoding

2011/3/1 Nikos Leontsinis <leontsinis <at> gmail.com>:
> I am not sure if implementors are obliged to honour this request.

I don't understand what you mean. I just said that # is not allowed in
a SIP URI username, no more. I don't know which "request" implementors
are obliged to honour or not.

--

-- 
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
Permalink | Reply | 2 comments |
headers
Brett Tate | 1 Mar 2011 13:23
Favicon

Re: 481/408 response on Re-INVITE

> Did I just misread the RFC and the dialog can just be cleaned
> up locally or is the UAC nevertheless supposed to send a BYE, 
> cleaning up the dialog when the BYE transaction finally 
> terminates? 

The following is from RFC 3261 section 12.2.1.2:

"If the response for a request within a dialog is a 481
(Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog if
no response at all is received for the request (the client
transaction would inform the TU about the timeout.)

   For INVITE initiated dialogs, terminating the dialog consists of
   sending a BYE."

For those interested, the 481 topic was discussed within IETF 49 SIP working group:
http://www.ietf.org/proceedings/49/
Permalink | Reply | 1 comment |

Gmane