Subject: Contact header ...

From: Shail Bhatnagar <[email-masked]>
Date: Wed, 02 Jun 1999 13:15:35 -0400

I see the following example Contact header in the RFC :

Contact: "Mr. Watson" <sip:[email-masked]>
        ;q=0.7; expires=3600,
        "Mr. Watson" <mailto:[email-masked]> ;q=0.1

1) Does this match with the syntax description or have I missed
something. Basically I want to know where exactly the spec states
that Contact header can have multiple locations separated by comma.

2) Also, I don't see any description of extension-attribute 
or extension-name.

3) What is the significance of expires for a UAC or UAS. In the 
following scenario :

UAC                                                UAS
--> INVITE   
     (with Contact and expires value)
                                            <-- 200 OK

<Call in progress>

                                             <-- BYE
At the time of sending the BYE, let us assume the contact location
has expired. Where should the UAS send the BYE ?

Thanks,

-- 
Best regards,
Shail

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jun 1999 10:28:47 -0400

Yes, it matches. Looking at the BNF:

>  Contact = ( "Contact" | "m" ) ":" 
>              ("*" | (1# (( name-addr | addr-spec )
>              [ *( ";" contact-params ) ] [ comment ] )))
> 

The 1# in the second line defines a comma separated list. From the annex
which describes BNF:

> #rule
> 
> 
>    A construct "#" is defined, similar to "*", for defining lists of
>    elements. The full form is "<n>#<m> element" indicating at least <n>
>    and at most <m> elements, each separated by one or more commas (",")
>    and OPTIONAL linear white space (LWS). This makes the usual form of
>    lists very easy; a rule such as
> 
> 

> 2) Also, I don't see any description of extension-attribute

You're right. I think we knew about this. Anyway, I believe they are
both tokens.

> has expired. Where should the UAS send the BYE ?

The purpose of Expires in INVITE is that it limits the lifetime of the
INVITE itself, not of the Contact header. The UAS should ring until the
time in the Expires header has been reached, and then send a timeout:

> For INVITE requests, it is a request and response-header field. In a
>    request, the caller can limit the validity of an invitation, for
>    example, if a client wants to limit the time duration of a search or
>    a conference invitation. A user interface MAY take this as a hint to
>    leave the invitation window on the screen even if the user is not
>    currently at the workstation. This also limits the duration of a
>    search. If the request expires before the search completes, the proxy
>    returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily)
>    response, a server can advise the client of the maximal duration of
>    the redirection.
> 

The spec also defines its use for REGISTER in limiting the lifetime of
the registration itself, which boils down to how long the URI's in the
Contact header are valid for. 

I guess your question came up since you are looking at placing an
expires parameter in the Contact header in the INVITE request. I'm not
sure if the spec says you shouldn't do this, but I don't think it makes
sense to limit the lifetime of the Contact parameter itself in an
INVITE. It already says somewhere in the spec that the Contact address
in the INVITE and 200 OK is valid for the entire call, but no longer.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen