×

Discussion Board

Results 1 to 9 of 9
  1. #1
    Registered User
    Join Date
    Aug 2004
    Posts
    32

    SIP content type

    Hi,

    I got one crucial question. Is there any way to use own content types other than sdp?

    I am trying to send SIP message with our own XML content and the terminal sip stack replyes with "415 Unsupported Media Type" accept: application/sdp.

    Would be nice if the application developer could make the desicion of supported media types instead of the SIP stack.

    I am using Nokia SIP Plug-in 4.0 for Series 60 (08.07.2005) for symbian

    Cheers,

    Henri

  2. #2
    Registered User
    Join Date
    Sep 2004
    Posts
    23

    Re: SIP content type

    About "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.3.5. of SIP specification (RFC 3261):

    " If a 415 (Unsupported Media Type) response is received (Section
    21.4.13), the request contained media types not supported by the UAS.
    The UAC SHOULD retry sending the request, this time only using
    content with types listed in the Accept header field in the response,
    with encodings listed in the Accept-Encoding header field in the
    response, and with languages listed in the Accept-Language in the
    response."

    About the usage of SDP protocol:

    18.1. B.1 Configuring Media Streams

    The caller and callee align their media descriptions so that the nth media stream ("m=" line) in the caller's session description corresponds to the nth media stream in the callee's description.

    All media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings.

    This allows easier migration away from static payload types.

    If the callee wants to neither send nor receive a stream offered by the caller, the callee sets the port number of that stream to zero in its media description.

    There currently is no other way than port zero for the callee to refuse a bidirectional stream offered by the caller. Both caller and callee need to be aware what media tools are to be started.

    For example, assume that the caller Alice has included the following description in her INVITE request. It includes an audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32).

    v=0
    o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
    c=IN IP4 host.anywhere.com
    m=audio 49170 RTP/AVP 0
    a=rtpmap:0 PCMU/8000
    m=video 51372 RTP/AVP 31
    a=rtpmap:31 H261/90000
    m=video 53000 RTP/AVP 32
    a=rtpmap:32 MPV/90000

    The callee, Bob, does not want to receive or send the first video stream, so it returns the media description below:

    v=0
    o=bob 2890844730 2890844730 IN IP4 host.example.com
    c=IN IP4 host.example.com
    m=audio 47920 RTP/AVP 0 1
    a=rtpmap:0 PCMU/8000
    a=rtpmap:1 1016/8000
    m=video 0 RTP/AVP 31
    m=video 53000 RTP/AVP 32
    a=rtpmap:32 MPV/90000

    18.2. B.2 Setting SDP Values for Unicast

    If a session description from a caller contains a media stream which is listed as send (receive) only, it means that the caller is only willing to send (receive) this stream, not receive (send). The same is true for the callee.

    For receive-only and send-or-receive streams, the port number and address in the session description indicate where the media stream should be sent to by the recipient of the session description, either caller or callee. For send-only streams, the address and port number have no significance and SHOULD be set to zero.

    The list of payload types for each media stream conveys two pieces of information, namely the set of codecs that the caller or callee is capable of sending or receiving, and the RTP payload type numbers used to identify those codecs. For receive-only or send-and-receive media streams, a caller SHOULD list all of the codecs it is capable of supporting in the session description in an INVITE or ACK. For send-only streams, the caller SHOULD indicate only those it wishes to send for this session. For receive-only streams, the payload type numbers indicate the value of the payload type field in RTP packets the caller is expecting to receive for that codec type. For send-only streams, the payload type numbers indicate the value of the payload type field in RTP packets the caller is planning to send for that codec type. For send-and-receive streams, the payload type numbers indicate the value of the payload type field the caller expects to both send and receive.

    If a media stream is listed as receive-only by the caller, the callee lists, in the response, those codecs it intends to use from among the ones listed in the request. If a media stream is listed as send-only by the caller, the callee lists, in the response, those codecs it is willing to receive among the ones listed in the the request. If the media stream is listed as both send and receive, the callee lists those codecs it is capable of sending or receiving among the ones listed by the caller in the INVITE. The actual payload type numbers in the callee's session description corresponding to a particular codec MUST be the same as the caller's session description.

    ****If caller and callee have no media formats in common for a particular stream, the callee MUST return a session description containing the particular "m=" line, but with the port number set to zero, and no payload types listed.

    If there are no media formats in common for all streams, the callee SHOULD return a 400 response, with a 304 Warning header field.****

    18.3. Multicast Operation

    The interpretation of send-only and receive-only for multicast media sessions differs from that for unicast sessions. For multicast, send-only means that the recipient of the session description (caller or callee) SHOULD only send media streams to the address and port indicated. Receive-only means that the recipient of the session description SHOULD only receive media on the address and port indicated.

    For multicast, receive and send multicast addresses are the same and all parties use the same port numbers to receive media data. If the session description provided by the caller is acceptable to the callee, the callee can choose not to include a session description or MAY echo the description in the response.

    A callee MAY, in the response, return a session description with some of the payload types removed, or port numbers set to zero (but no other value). This indicates to the caller that the callee does not support the given stream or media types which were removed. A callee MUST NOT change whether a given stream is send-only, receive-only, or send-and-receive.

    If a callee does not support multicast at all, it SHOULD return a 400 status response and include a 330 Warning.
    18.4. B.4 Delayed Media Streams

    In some cases, a caller may not know the set of media formats which it can support at the time it would like to issue an invitation. This is the case when the caller is actually a gateway to another protocol which performs media format negotiation after call setup. When this occurs, a caller MAY issue an INVITE with a session description that contains no media lines. The callee SHOULD interpret this to mean that the caller wishes to participate in a multimedia session described by the session description, but that the media streams are not yet known. The callee SHOULD return a session description indicating the streams and media formats it is willing to support, however. The caller MAY update the session description either in the ACK request or in a re-INVITE at a later time, once the streams are known.
    18.5. B.5 Putting Media Streams on Hold

    If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more media streams, a party re-invites the other by sending an INVITE request with a modified session description. The session description is the same as in the original invitation (or response), but the "c" destination addresses for the media streams to be put on hold are set to zero (0.0.0.0).
    18.6. B.6 Subject and SDP "s=" Line

    The SDP "s=" line and the SIP Subject header field have different meanings when inviting to a multicast session. The session description line describes the subject of the multicast session, while the SIP Subject header field describes the reason for the invitation. The example in Section 16.2 illustrates this point. For invitations to two-party sessions, the SDP "s=" line MAY be left empty.
    18.7. B.7 The SDP "o=" Line

    The "o=" line is not strictly necessary for two-party sessions, but MUST be present to allow re-use of SDP-based tools.

  3. #3
    Registered User
    Join Date
    Aug 2004
    Posts
    32

    Re: SIP content type

    Thanks for your quick and descriptive reply
    So, to conclude your reply: SIP messages cannot be used to carry any other content that sdp. Is this right?

  4. #4
    Registered User
    Join Date
    Sep 2004
    Posts
    23

    Re: SIP content type

    Session Initiation Protocol (SIP) is an application-layer control protocol (defined in RFC 2543) that can be used to establish, maintain, and terminate calls between two or more end points. In that sense, the content is "not carried" by SIP protocol (media can be sent using for example RTP protocol). The SIP protocol is only utilized to establish the session. SIP refers to the media format to be utilized in the session using SDP (Session Description Protocol). So, as you mentioned, we could say that SIP carries SDP information, and SDP carries (among other descriptive information related to the session) which is the media format to be utilized in the session.

    These are the fields in SDP message:

    Session description
    v= (protocol version)
    o= (owner/creator and session identifier).
    s= (session name)
    i=* (session information)
    u=* (URI of description)
    e=* (email address)
    p=* (phone number)
    c=* (connection information - not required if included in all media)
    b=* (bandwidth information)
    One or more time descriptions (see below)
    z=* (time zone adjustments)
    k=* (encryption key)
    a=* (zero or more session attribute lines)
    Zero or more media descriptions (see below)

    Time description
    t= (time the session is active)
    r=* (zero or more repeat times)

    Media description
    m= (media name and transport address)
    i=* (media title)
    c=* (connection information - optional if included at session-level)
    b=* (bandwidth information)
    k=* (encryption key)
    a=* (zero or more media attribute lines)



    * About SIP:

    SIP provides the capabilities to:

    Determine the location of the target end point—SIP supports address resolution, name mapping, and call redirection.

    Determine the media capabilities of the target end point—Via Session Description Protocol (SDP), SIP determines the "lowest level" of common services between the end points. Conferences are established using only the media capabilities that can be supported by all end points.

    Determine the availability of the target end point—If a call cannot be completed because the target end point is unavailable, SIP determines whether the called party is already on the phone or did not answer in the allotted number of rings. It then returns a message indicating why the target end point was unavailable.

    Establish a session between the originating and target end point—If the call can be completed, SIP establishes a session between the end points. SIP also supports mid-call changes, such as the addition of another end point to the conference or the changing of a media characteristic or codec.

    Handle the transfer and termination of calls—SIP supports the transfer of calls from one end point to another. During a call transfer, SIP simply establishes a session between the transferee and a new end point (specified by the transferring party) and terminates the session between the transferee and the transferring party. At the end of a call, SIP terminates the sessions between all parties.

    * About SDP

    SDIP is a protocol that defines a text-based format for describing streaming media sessions and multicast transmissions. SDP is not a transport protocol but a method of describing the details of the transmission. For example, an SDP file contains information about the format, timing and authorship of the transmission, name and purpose of the session, any media, protocols or codec formats, the version number, contact information and broadcast times.
    Last edited by antogarforum; 2005-12-02 at 15:25.

  5. #5
    Registered User
    Join Date
    Aug 2004
    Posts
    32

    Re: SIP content type

    Thanks again for your reply.
    I have been working with the implementation and I have advanced and encountered another problem. Now I have used the invite procedure from the terminal side to create a dialog within the terminal SIP stack. (I found that within dialog, reguest can be sent from either end, server or terminal RFC 3261 12.2)
    Now I am able to receive SIP MESSAGE generated by the server with custom content type (The terminal SIP stack won't reject the message since I use from and to tags, and the call-id with incremented Cseq number of invite). When I receive the message I reply with OK 200 which is received by the server with no problems.

    The problem arises when I try to send another SIP message from the server (Message is same despite the cSeg numer which is again incremented by one) the terminal SIP stack replies with the same OK 200 (Headers and the cSeq numer is the same of previous message what I sent, not the one in the new message) and wont let the SIP message pass to the application developer layer. If I understand the RFC 3261 (8.1.1.5)(12.2.1.1) specification correctly the cSeq number identifies within dialog that messages are different from other transactions carried out within the dialog?

    I have a feeling that this might be a bug in the SIP stack. Have anybody encountered similar behaviour or solution for it?

    Cheers,

    Henri
    Last edited by hlothman; 2005-12-15 at 08:18.

  6. #6
    Registered User
    Join Date
    Aug 2004
    Posts
    32

    Thumbs up Re: SIP content type

    No bug found from the SIP stack. The reason for the automatic SIP stack OK 200 reply was that
    I did not regenerate the Via branch value for each message request sent by the server.
    Now everything works as charm

    Thanks everybody!

  7. #7
    Registered User
    Join Date
    Dec 2005
    Location
    Italy
    Posts
    12

    Re: SIP content type

    Sorry, how did you manage your application to receive SIP MESSAGEs? Mine is still rejecting all MESSAGE requests with a 415 unsupported media type. What did you write in the opaque_data field? Thank you
    Dario

  8. #8
    Regular Contributor
    Join Date
    Oct 2005
    Location
    Mumbai, India
    Posts
    103

    Re: SIP content type

    Hi,
    the 415 unsupported media type is due to that you are sending a request that the server cant understand..you can give the ACCEPT VALUE in your opaque_data field as text/html and you should use text/html as your content type in SIP MESSAGE requests..hope it will help you

    regards
    Rafeeq

  9. #9
    Registered User
    Join Date
    Dec 2005
    Location
    Italy
    Posts
    12

    Re: SIP content type

    Thank you, now it works.

Similar Threads

  1. SIP INVITE Message. Content type not set
    By chengiz in forum Symbian Networking & Messaging (Closed)
    Replies: 0
    Last Post: 2005-05-25, 12:15
  2. SIP multipart/mixed content
    By jgarinf in forum Symbian Networking & Messaging (Closed)
    Replies: 10
    Last Post: 2005-01-21, 04:05
  3. D211 with RH7.3
    By fiveam in forum Multimodecards
    Replies: 3
    Last Post: 2003-02-24, 10:06
  4. D211 : Compiling the user interface for Linux...?
    By franz_meyer in forum Multimodecards
    Replies: 1
    Last Post: 2002-12-09, 12:48
  5. Problem with Nokia D211 Linux Drivers
    By fiveam in forum Multimodecards
    Replies: 1
    Last Post: 1970-01-01, 01:00

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×