DDevelopment & Design

SIP & SDP – Session Description Protocol

  • byTouK
  • August 5, 2008
  • 2 minute read

Protokołu SIP jest protokołem sygnalizacyjnym używanym do inicjowania sesji multimedialnych. SIP umożliwiają realizacje negocjacji charakterystyki sesji oraz jej aktualizacje ale sam w sobie nie zawiera mechanizmów do opisu kształtu sesji, przenoszonej za pomocą protkołu RTP. W tym celu SIP wykorzystuje protokół SDP (Session Descriptions Protocol)
wchodzący bezpośrednio w skład komunikatu. SDP zawiera informacje o rodzaju
mediów, kodekach i ich parametrach, adresach IP, kierunku strumieniów, dostępnym pasmie itp.

Opis sesji:

  • v= (protocol version) – wersja protokołu -> “0”
  • o= (originator and session identifier) – zrodlo i identyfikator sesji -> “dowolna_nazwa id_sesji wersja_sesji IN (IP4|IP6) adresIP_zródła_sesji”
  • s= (session subject) – temat sesjii -> “-“
  • i=* (session information) – opis sesji -> nie używany
  • u=* (URI of description) – uri dodatkowe opisu sesji -> nie używany
  • e=* (email address) – adres email osoby odpowiedzialnej za sesje -> nie używany
  • p=* (phone number) – numer telefoniczny osoby odpowiedzialnej za sesje -> nie używany
  • c=* (connection information) – opis połaczenia, nie wymagany jeśli obecny dla każdego strumienia mediów -> “IN (IP4|IP6) adresIP”
  • b=* (zero or more bandwidth information lines) – sugerowane pasmo -> nie używany
  • One or more time descriptions
  • z=* (time zone adjustments)- definicja strefy czasu -> nie używany
  • k=* (encryption key) – klucz szyfrujący -> nie używane
  • a=* (zero or more session attribute lines) – atrybuty: sendonly – jeśli strona tylko chce wysyłać media, recvonly – jeśli strona chce tylko odbierać media, inactive – bez mediów, sendrecv – jeśli strona chce wysyłać i odbierać media
  • Zero or more media descriptions

Opis Czasu:

  • t= (time the session is active) – czas sesji -> “0 0”
  • r=* (zero or more repeat times) – cykliczność sesji -> nie używany

Opis Mediów:

  • m= (media name and transport address) – opis mediów -> “(audio|video|text) RTP/AVP opis danych medialnych”
  • i=* (media title) – opis mediów -> nie używany
  • c=* (connection information) – opis połaczenia, nie wymagany jeśli obecny w opisie sesji, nadpisuje wartość z opisu sesji -> “IN (IP4|IP6) AdresIP”
  • b=* (zero or more bandwidth information lines) – sugerowane pasmo -> nie używany
  • k=* (encryption key) – klucz szyfrujący -> nie używane
  • a=* (zero or more media attribute lines)  – atrybuty strumienia, nadpisują atrybuty zdefiniowane w opisie sesji: sendonly – jeśli strona tylko chce wysyłać media, recvonly
    – jeśli strona chce tylko odbierać media, inactive – bez mediów,
    sendrecv – jeśli strona chce wysyłać i odbierać media, rtcp – port dla rtcp jesli nie, ptime – dlugosc mediów w sekunadach w przesylanym pakiecie, rtpmap – mapuje numer typu zawartosci do konkretnego kodeka i jego czestotliwosci, fmtp – umożliwia mapowanie parametrow tak aby sdp nie musialo tego rozumiec

— Previous article

Sygnalizacyjne ABC

Next article —

RTMP - Real Time Messaging Protocol

You May Also Like
DDevelopment & Design

Read emails from imap with Spring Intergration

What's the easiest way to read emails from IMAP account in Java? Depends what your background is. If you have any experience in Apache Camel, ServiceMix, Mule, you already know the answer. If you don't, and your application is using Spring alr...What's the easiest way to read emails from IMAP account in Java? Depends what your background is. If you have any experience in Apache Camel, ServiceMix, Mule, you already know the answer. If you don't, and your application is using Spring alr...
DDevelopment & Design

Private fields and methods are not private in groovy

I used to code in Java before I met groovy. Like most of you, groovy attracted me with many enhancements. This was to my surprise to discover that method visibility in groovy is handled different than Java!

Consider this example:

class Person {
private String name
public  String surname

private Person() {}

private String signature() { "${name?.substring(0, 1)}. $surname" }

public String toString() { "I am $name $surname" }
}

How is this class interpreted with Java?

  1. Person has private constructor that cannot be accessed
  2. Field "name" is private and cannot be accessed
  3. Method signature() is private and cannot be accessed

Let's see how groovy interpretes Person:

public static void main(String[] args) {
def person = new Person()   // constructor is private - compilation error in Java
println(person.toString())

    person.@name = 'Mike'       // access name field directly - compilation error in Java
println(person.toString())

    person.name = 'John'        // there is a setter generated by groovy
println(person.toString())

    person.@surname = 'Foo'     // access surname field directly
println(person.toString())

    person.surname = 'Bar'      // access auto-generated setter
println(person.toString())

println(person.signature()) // call private method - compilation error in Java
}

I was really astonished by its output:

I am null null
I am Mike null
I am John null
I am John Foo
I am John Bar
J. Bar

As you can see, groovy does not follow visibility directives at all! It treats them as non-existing. Code compiles and executes fine. It's contrary to Java. In Java this code has several errors, pointed out in comments.

I've searched a bit on this topic and it seems that this behaviour is known since version 1.1 and there is a bug report on that: http://jira.codehaus.org/browse/GROOVY-1875. It is not resolved even with groovy 2 release. As Tim Yates mentioned in this Stackoverflow question: "It's not clear if it is a bug or by design". Groovy treats visibility keywords as a hint for a programmer.

I need to keep that lesson in mind next time I want to make some field or method private!