Jump to content
Калькуляторы

SIP SDP double CRLF

Добрый день !

Вопрос к знатокам сигнализации SIP. Допустимо ли использовать двойную последовательность CRLF в завершении SIP сообщения, содержащего SDP в частности ?

 

Самостоятельно нашел http://www.faqs.org/rfcs/rfc2327.html "Text records such as the session name and information are bytes strings which may contain any byte with the exceptions of 0x00 (Nul),

0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers should be

tolerant and also accept records terminated with a single newline character. By default these byte strings contain ISO-10646

characters in UTF-8 encoding, but this default may be changed using the `charset' attribute."

 

Вроде как прямого запрета нет, но и про допустимость ни слова.

 

Нашел только некий драфт http://tools.ietf.org/html/draft-ietf-sip-rfc2543bis-02 в котором четко написано "Senders MUST terminate lines with a CRLF, but receivers MUST also interpret CR and LF by themselves as

line terminators. Only the combinations CR CR, LF LF and CRLF CRLF terminate the message header."

 

 

Share this post


Link to post
Share on other sites
Добрый день !

Вопрос к знатокам сигнализации SIP. Допустимо ли использовать двойную последовательность CRLF в завершении SIP сообщения, содержащего SDP в частности ?

 

Самостоятельно нашел http://www.faqs.org/rfcs/rfc2327.html "Text records such as the session name and information are bytes strings which may contain any byte with the exceptions of 0x00 (Nul),

0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers should be

tolerant and also accept records terminated with a single newline character. By default these byte strings contain ISO-10646

characters in UTF-8 encoding, but this default may be changed using the `charset' attribute."

 

Вроде как прямого запрета нет, но и про допустимость ни слова.

 

Нашел только некий драфт http://tools.ietf.org/html/draft-ietf-sip-rfc2543bis-02 в котором четко написано "Senders MUST terminate lines with a CRLF, but receivers MUST also interpret CR and LF by themselves as

line terminators. Only the combinations CR CR, LF LF and CRLF CRLF terminate the message header."

 

Думается, что смотреть надо в первую очередь в RFC 3261

 

7 SIP Messages

   SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279
   [7]).

   A SIP message is either a request from a client to a server, or a
   response from a server to a client.

   Both Request (section 7.1) and Response (section 7.2) messages use
   the basic format of RFC 2822 [3], even though the syntax differs in
   character set and syntax specifics.  (SIP allows header fields that
   would not be valid RFC 2822 header fields, for example.)  Both types
   of messages consist of a start-line, one or more header fields, an
   empty line indicating the end of the header fields, and an optional
   message-body.

         generic-message  =  start-line
                             *message-header
                             CRLF
                             [ message-body ]
         start-line       =  Request-Line / Status-Line

   The start-line, each message-header line, and the empty line MUST be
   terminated by a carriage-return line-feed sequence (CRLF).  Note that
   the empty line MUST be present even if the message-body is not.

 

.

Share this post


Link to post
Share on other sites
Думается, что смотреть надо в первую очередь в RFC 3261

Может мне не по глазам, не вижу ни слова про двойную последовательность. Да и для SDP отдельный RFC есть :)

 

Помимо всего выше перечисленного нашел такое письмо https://lists.cs.columbia.edu/pipermail/sip...ary/002576.html . Конечно понимаю что данный лист рассылки никак на RFC ни тянет, но это единственное что смог найти по теме.

 

Немного уточню, есть наш СС, есть некий ТА, все SIP/SDP сообщения от нашего СС завершаются CRLF CRLF последовательностью, шлюз завершает соединения с 500 ошибкой. Вопрос стандартен для России :) "Кто виноват ?"

Share this post


Link to post
Share on other sites
Думается, что смотреть надо в первую очередь в RFC 3261
[...]

Немного уточню, есть наш СС, есть некий ТА, все SIP/SDP сообщения от нашего СС завершаются CRLF CRLF последовательностью, шлюз завершает соединения с 500 ошибкой. Вопрос стандартен для России :) "Кто виноват ?"

Я себе представляю этот диалог так:

 

- INVITE ( REQUEST-LINE CRLF, Header CRLF, Header CRLF, CRLF (разделение от message body), SDP line CRLF, ... SDP line CRLF )

- 100 Trying ( STATUS-LINE CRLF, Header CRLF, Header CRLF, CRLF (2 CRLF в завершении пакета) )

- 180 Ringing ( STATUS-LINE CRLF, Header CRLF, Header CRLF, CRLF (2 CRLF в завершении пакета) )

- 183 Ringing / 200 OK ( STATUS-LINE CRLF, Header CRLF, Header CRLF, CRLF (разделение от message body), SDP line CRLF, ... SDP line CRLF )

- ACK ( REQUEST-LINE CRLF, Header CRLF, Header CRLF, CRLF )

- ....

- BYE ( REQUEST-LINE CRLF, Header CRLF, Header CRLF, CRLF )

- 200 OK ( STATUS-LINE CRLF, Header CRLF, Header CRLF, CRLF )

 

 

Если все SIP/SDP сообщения c CRLFCRLF на конце, то виноват ваш SoftSwitch.

 

.

Edited by Voicemaster

Share this post


Link to post
Share on other sites

недопонимание закралось, это выглядит так -

....

183 Ringing / 200 OK ( STATUS-LINE CRLF, Header CRLF, Header CRLF, CRLF (разделение от message body), SDP line CRLF, ... SDP line CRLF )CRFL

...

 

в конце SDP секции завершающая последовательность CRLF, не в конце каждой строки.

 

ЗЫ Я сильно бы хотелось подтверждение вины :) без доказательств не будет пилить ни СС ни шлюз :( Я их найти не смог, точной формулировки нет, хотя и нигде нет прямого указания на недопустимость завершающей последовательности.

Edited by Eugene Tsepelev

Share this post


Link to post
Share on other sites
недопонимание закралось, это выглядит так -

....

183 Ringing / 200 OK ( STATUS-LINE CRLF, Header CRLF, Header CRLF, CRLF (разделение от message body), SDP line CRLF, ... SDP line CRLF )CRFL

...

 

в конце SDP секции завершающая последовательность CRLF, не в конце каждой строки.

 

ЗЫ Я сильно бы хотелось подтверждение вины :) без доказательств не будет пилить ни СС ни шлюз :( Я их найти не смог, точной формулировки нет, хотя и нигде нет прямого указания на недопустимость завершающей последовательности.

Должно выглядеть как:

 

- 183 Ringing ( STATUS-LINE CRLF, Header CRLF, Header CRLF, CRLF (разделение от message body), SDP line CRLF, ... SDP line CRLF )

- 200 OK ( STATUS-LINE CRLF, Header CRLF, Header CRLF, CRLF (разделение от message body), SDP line CRLF, ... SDP line CRLF )

 

В конце пакета 1 CRLF. Это моё IMHO, разумеется. Дальше только Google в помошь.

 

 

P.S.

Возьмите уже снифер в руки что ли, погоняйте разное оборудование.

 

.

Share this post


Link to post
Share on other sites

Брал - гонял, у 70 процентов нет CLRF, у 30 есть.

 

ЗЫ Будем думать и искать...

Share this post


Link to post
Share on other sites
Брал - гонял, у 70 процентов нет CLRF, у 30 есть.

 

ЗЫ Будем думать и искать...

Чего искать ? Запатчить SoftSwitch на нормальный CRLF - дело 10 минут. Потом ещё и спасибо должны сказать.

 

BTW, а у какой софтины такие косяки, если это не ДСП, разумеется ?

 

.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this