Monthly Archives: January 2014

Tools for a Telecom software Engineer

evernote    desktop

  • Evernote for notekeeping
  • Eclipse to do real programming

github  mysql

  • Github to upload download code
  • MySQL  workbench to take care of Database Management

 

 

Technologies to Work with

 wenrtc players icon

  •  IETF
  • W3C
  • WebRTC
  • HTML
  • Java
  • GSMS standards

 

 

 

tools

Frameworks

frameworks

  • Struts
  • Hibernate
  • Spring
  • EJB

 

SIP and SDP Messages Explained

Traditional SIP headers for Call setup are INVITE, ACK and teardown are CANCEL or BYE
However with more adoption newer methods specific to services were added such as
MESSAGE Methods for Instant Message based services
SUBSCRIBE, NOTIFY standardised by Event notification extension RFC 3856
PUBLISH to push presence information to the network

Outlining the SIP Requests and Responses in tables below,

1. Request Message

Request Message

Description

REGISTERA Client use this message to register an address with a SIP server
INVITEA User or Service use this message to let another user/service participate in a session. The body of this message would include a description of the session to which the callee is being invited.
ACKThis is used only for INVITE indicating that the client has received a final response to an INVITE request
CANCELThis is used to cancel a pending request
BYEA User Agent Client use this message to terminate the call
OPTIONSThis is used to query a server about its capabilities

2. Response Message

Code

Category

Description

1xxProvisionalThe request has been received and processing is continuing
2xxSuccessAn ACK, to indicate that the action was successfully received, understood, and accepted.
3xxRedirectionFurther action is required to process this request
4xxClient ErrorThe request contains bad syntax and cannot be fulfilled at this server
5xxServer ErrorThe server failed to fulfill an apparently valid request
6xxGlobal FailureThe request cannot be fulfilled at any server

, based on RFC 3261

SIP headers :

Display names

From originators sipuri

CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.

Contact – SIP URI that represents a direct route to the originator usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. The Contact header field tells other elements where to send future requests.

Max-Forwards -to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.

Content-Type – description of the message body. ex : application/h.323

Content-Length – an octet (byte) count of the message body.

Accept – acceptable formats like application/sdp or currency/dollars

Authorization – encryption info

Call-Id uniquely identify a session

contact – sip url alternative for direct routing

Encryption

Expires – when msg content is no longer valid

Mandatory SIP headers

  • INVITE sip:altanai@domain.comSIP/2.0
  • Via: SIP/2.0/UDP host.domain.com:5060
  • From: Bob <sip:bob@domain.com>
  • To: Altanai <sip:domain@wcom.com>
  • Call-ID: 163784@host.domain.com
  • CSeq: 1 INVITE

session description in SDP

sdp

SDP /Session Description Protocol

standard for protocol definition for exchange of media ( RFC 4566)

SDP is encapsulated inside of SIP packet

TYPICAL SIP INVITE :

INVITEnbspsip:01150259917040@x.x.x.x SIP/2.0
 Via: SIP/2.0/UDP x.x.x.x:5060branch=z9hG4bK400fc6e6
 From: "123456789" ltsip:123456789@x.x.x.xgttag=as42e2ecf6
 To: ltsip:01150259917040@x.x.x.x.4gt
 Contact: ltsip:123456789@x.x.x.x4gt
 Call-ID: 2485823e63b290b47c042f20764d990a@x.x.x.x.x
 CSeq: 102 INVITE
 User-Agent:nbspMatrixSwitch
 Date: Thu, 22 Dec 2005 18:38:28 GMT
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
 Content-Type: application/sdp
 Content-Length: 268
 v=0
 o=root 14040 14040 IN IP4 x.x.x.x
 s=session
 c=IN IP4 x.x.x.x
 t=0 0
 m=audio 26784 RTP/AVP 0 8 18 101
 a=rtpmap:0 PCMU/8000
 a=rtpmap:8 PCMA/8000
 a=rtpmap:18 G729/8000
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-16
 a=fmtp:18nbspannexb=no - - - -
 c=* (connection information - optional if included at session-level)
 b=* (bandwidth information)
 a=* (zero or more media attribute lines)

SIP Responses

1xx—Provisional Responses

response that tells to its recipient that the associated request was received but result of the processing is not known yet which could be if the processing hasnt finished immediately. The sender must stop retransmitting the request upon reception of a provisional response.

100 Trying
180 Ringing
181 Call is Being Forwarded
182 Queued
183 Session in Progress199 Early Dialog Terminated

2xx—Successful Responses

final responses express result of the processing of the associated request and they terminate the transactions.

200 OK
202 Accepted
204 No Notification

3xx—Redirection Responses

redirection response gives information about the user’s new location or an alternative service that the caller should try for the call. Used for cases when the server cant satisfy the call and wants the caller to try elsewhere . After this the caller is suppose to resend the request to the new location.

300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service

4xx—Client Failure Responses

negative final responses indicating that the request couldn’t be processed  due to callers fault , for reasons such as t contains bad syntax or cannot be fulfilled at that server.

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Conditional Request Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
417 Unknown Resource-Priority
420 Bad Extension
421 Extension Required
422 Session Interval Too Small
423 Interval Too Brief
424 Bad Location Information
428 Use Identity Header
429 Provide Referrer Identity
430 Flow Failed
433 Anonymity Disallowed
436 Bad Identity-Info
437 Unsupported Certificate
438 Invalid Identity Header
439 First Hop Lacks Outbound Support
470 Consent Needed
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
482 Loop Detected.
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
489 Bad Event
491 Request Pending
493 Undecipherable
494 Security Agreement Required

5xx—Server Failure Responses

negative responses but indicating that fault is at server’s side for cases such as server cant or doesnt want to respond the the request.

500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
580 Precondition Failure

6xx—Global Failure Responses

request cannot be fulfilled at any server with definitive information

600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable

Mandatory Headers in SIP Response 
  • SIP/2.0 200 OK
  • Via: SIP/2.0/UDP host.domain.com:5060
  • From: Bob<sip:bob@domain.com>
  • To: Altanai<sip:altanai@domain.com>
  • Call-ID: 163784@host.domain.com
  • CSeq: 1 INVITE

Via, From, To, Call-ID , and  CSeq  

are copied exactly from Request. 

You can read more about SIP based Architecture here :SIP based architecture

Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)

An INVITE request sent within an existing dialog is known as a re-INVITE.
A re-Invite has an offer-answer exchange and can be used to

change the session and/or dialog params
change the port to which media should be sent.
change the connection address or media type.
Hold/Release and SUSPEND/RESUME rtp streams (connection address is zero).
FAX (T.38 and Bypass).

Re-INVITE with SDP useCases

  1. UAS rejects all changes in params in re-INVITE

Situtaion where UAC establishes audio only call
SDP1: m=audio 30000 RTP/AVP 0

but later wants to upgrade to video as well
SDP:m=audio 30000 RTP/AVP 0
m=video 30002 RTP/AVP 31

UAS configured to reject video streams, can reject this with a 4XX error and get ACK .
No changes to session are made

  1. UAS receives re-INVITE for param but wants to accept few and reject others, it sends back SDP with acceptable changes with 200 OK

For instance UAC moves to high bandwidth access point and wants to update IP of media stream . It also wanst to add video stream

initial SDP
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1

new SDP in reINVITE
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2

UAS returns a 200 (OK) response to accept IP but sets the port of the video stream to zero in its SDP to show rejected of video stream.

m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31

another example is when UAC wwants to add anotehr audio codec and also add video stream to session

orignal SDP
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1

re-invite SDP
m=audio 30000 RTP/AVP 0 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1

again the UAS will optionally accept the some param canges like audio code but set video to null IP address

m=audio 31000 RTP/AVP 0 3
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0

  1. UAS receives re-INVITE but wants for user intervention

UAS receives re-INVITE to add video , but instead of rejecting , it prompts user to permit.

So UAS provides a null IPaddress instead of setting the stream to ‘inactive’ because inactive streams still need to exchange RTP Control Protocol (RTCP) traffic
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0

Later if user rejects the addition of the video stream. Consequently, the UAS sends an UPDATE request (6) setting the port of the video stream to zero in its offer.
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0

Ref:
RFC 6141 Updates the RFC 3261 with respect to re-INVITE and UAS behaviour
https://tools.ietf.org/html/rfc6141