Σκέψεις περί SIP implementations και άλλα

[cosmos]

Κάποιο σκορπιοχώρι σκέψεων για το θέμα SIP. Κάτι σε blog, αλλά μια που δεν έχω σχετική σελίδα και βαριέμαι να ψάξω, τα γράφω εδώ.

Κατ'αρχήν μου φαίνεται μεγάλη υπόθεση που παίζουν οι συσκευές σε SIP. Μέσα σε λίγο καιρό έχω δει ΑΤΑ/softphones από τη μία αλλά και SIP servers να κάνουν ότι γουστάρουν, βιάζοντας κατά συρροή και κατ'εξακολούθηση τα σχετικά πρότυπα... Απορίας άξιον πως έχουμε VoIP που δουλεύει. Λ.χ.:

- O parser του Voipbuster & SIPDiscount μπορεί να μην αποδέχεται (λόγω σφάλματος) συγκεκριμένα codecs
- Στο (αγαπημένο μου κατά τα άλλα) Fritz Box Fon, έχω μετρήσει τουλάχιστον μία προφανή παραβίαση των specs και κανά 2 ακόμα αποκλίσεις από recommended (μη υποχρεωτικές, αλλά ισχυρά συνιστώμενες) προδιαγραφές.
- Με ένα quick peek στο evoice (παλιά υποδομή) υπάρχει τουλάχιστον μία προφανή παραβίαση των specs.
- Σειρά έχει το i-call να δω τι παίζει...

Εδώ πρέπει να πω ότι όσο αφορά τα σχετικά φθηνά routers-ata combos, τα Vigor φαίνεται να μην παίζονται σε επίπεδο βρέθηκε bug -> υποβλήθηκε -> βγήκε πατσάκι (νέο firmware)...

Αν έπαιρνα 1$ για κάθε bug που υπέβαλλα... :p

Τέσπα, βρήκα και κάτι άξιο λόγου για το πως δουλεύει η συνενόηση μεταξύ SIP client και server για την επιλογή του codec. Αρκετά μπερδεμένο, αλλά με λίγα λόγια πάει κάπως έτσι:
1) Ο client προσφέρει κάποια codec, λ.χ. g729, iLBC, g711a, g711u με αυτή τη σειρά. Το πρώτο codec είναι αν θέλετε και το προτιμητέο, αλλά δε δεσμεύει το server για την επιλογή του codec που θα χρησιμοποιηθεί

2) Με το που θα το πάρει ο server, σχηματίζει μία απάντηση στην οποία πρέπει να δηλώσει και αυτός κάποια codec με συγκεκριμένη σειρά, εκ των οποίων το πρώτο το θεωρεί από τη μεριά του ως προτεινόμενο (όχι για αποχώρηση).
Τώρα, εδώ είναι κομμάτι μπερδεμένο. Αν νομίζατε ότι εδώ περιλαμβάνονται μόνο τα codecs που προσφέρθηκαν από τον client, χάσατε. Τι πρέπει οπωσδήποτε να υπάρχει και τι συνίσταται να υπάρχει;
- Υποχρεωτικά πρέπει να υπάρχει στην απάντηση του server τουλάχιστον ένα από τα codecs που δηλώθηκαν στην προσφορά του client
- Υποχρεωτικά πρέπει στην απάντηση του server να μην αναγράφονται codecs που προσφέρθηκαν από τον client, αλλά δεν υποστηρίζονται από τον server
- Μπορεί η απάντηση να περιέχει και άλλα codecs λ.χ. η απάντηση να έχει τα εξής "g729,g726-32,g726-24,g723" (όπου εδώ θεωρείται ότι τα iLBC και τα G711 δεν υποστηρίζονται από το server, αλλιώς ο τελευταίος θα έπρεπε να τα βάλει και αυτά)
- Αν από τα codecs της αρχικής προσφοράς υποστηρίζονται πολλά από το server, τότε συνίσταται και η απάντηση να τα έχει με την ίδια σειρά. Mε άλλα λόγια, αν ο server υποστηρίζει τα ίδια ακριβώς codec με την προσφορά του client, η συνιστώμενη απάντηση είναι "g729, iLBC, g711a, g711u". Αλλά είναι σωστή και μία απάντηση του τύπου "g711a, g711u, g729, iLBC"!

3) Τώρα η απάντηση έχει σχηματιστεί. Μία σειρά από codecs λοιπόν έχει αποστελεί προς τον client, όπου συνήθως το πρώτο codec που αναφέρεται είναι και το προτιμώμενο από την πλευρά του server αλλά και υποστηρίζεται από τον client.
To ενδιαφέρον τώρα ποιο είναι: ο server με το που στέλνει την απάντηση μπορεί αμέσως να αρχίσει να στέλνει πληροφορία φωνής με χρήση του συνιστώμενου (από αυτόν) codec.

Ηθικόν δίδαγμα: τον κ**ο σας να βαράτε να θέλετε να βγει ένα codec, όταν δηλώνετε στις προτιμήσεις σας περισσότερα από ένα, ο server μπορεί να διαλέξει όποιο του γουστάρει... Ο σίγουρος τρόπος για να χρησιμοποιείται ο προτιμώμενός σας codec είναι να είναι ενεργός στον client σας μόνον αυτός...

Πέρα από αυτό, ενδιαφέρουσα φαίνεται η χρήση κανονικών αριθμών τηλεφώνων στη νέα υποδομή του evoice. Ο δρόμος που θα πάει το πράμα 99%.

Ακόμα πιο ενδιαφέρουσα (αν την έχω καταλάβει καλά) η δυνατότητα να καλείς έναν αριθμό 800, να δίνεις τα στοιχεία του evoice account που έχεις και στη συνέχεια να πραγματοποιείς κλήσεις προς τον προορισμό σου. Δωρεάν φυσικά αν είναι προς έτερους voip users.

Αλλά και η δυνατότητα interworking με ENUM, FWD και άλλους χρήστες, χωρίς χρήση SIP διεύθυνσης της μορφής χχχχ@fwdnet. Απλά με το αριθμητικό πρόθεμα. Αν το i-Call έχει κάτι αντίστοιχο interworking με FWD για παράδειγμα, θα είναι πολύ απλό να καλεί κάποιος από evoice -> icall και αντίστροφα, από το τηλέφωνο απλά με χρήση ίσως ένός προθέματος (λ.χ. **0).

[cosmos]

Έψαχνα να βρω τι παίζει με τις "βελτιωμένες" υλοποιήσεις i-Call και HOL.

- Στην μεν HOL δηλώνεις τι payload (σε msec) θες να κουβαλά κάθε πακέτο.

- Στο i-Call το "επίπεδο 1" αντιστοιχεί σε 110bytes payload σε G.729 -> μάλλον πρόκειται για πακέτα διάρκειας ... 110msec (μια που το default φορτίο των 20msec "μεταφράζεται" σε 20bytes φορτίου).

Το ενδιαφέρον είναι ότι σε διάφορες υλοποιήσεις ΑΤΑ που έχω δει, μπορείς να δηλώσεις το μέγεθος των πακέτων που στέλνεις εσύ. Μέσω του SDP θα μπορούσε το ΑΤΑ να δηλώσει την προτίμησή του για το τι πακέτα να στέλνει προς εμάς η άλλη πλευρά.

Με απλά λόγια. Αν υπήρχε μία επιλογή ας πούμε "Preferred received packet size (msec)" θα ήταν άχρηστες αυτές οι βελτιώσεις του i-call και του evoice... Δεν ξέρω αν υπάρχει σε ΑΤΑ τέτοια επιλογή. Ή αν υπάρχει, αν ο server θα τις σεβαστεί. Μπερδεμένο πράμα...

[sdikr]

Έψαχνα να βρω τι παίζει με τις "βελτιωμένες" υλοποιήσεις i-Call και HOL.

- Στην μεν HOL δηλώνεις τι payload (σε msec) θες να κουβαλά κάθε πακέτο.

- Στο i-Call το "επίπεδο 1" αντιστοιχεί σε 110bytes payload σε G.729 -> μάλλον πρόκειται για πακέτα διάρκειας ... 110msec (μια που το default φορτίο των 20msec "μεταφράζεται" σε 20bytes φορτίου).

Το ενδιαφέρον είναι ότι σε διάφορες υλοποιήσεις ΑΤΑ που έχω δει, μπορείς να δηλώσεις το μέγεθος των πακέτων που στέλνεις εσύ. Μέσω του SDP θα μπορούσε το ΑΤΑ να δηλώσει την προτίμησή του για το τι πακέτα να στέλνει προς εμάς η άλλη πλευρά.

Με απλά λόγια. Αν υπήρχε μία επιλογή ας πούμε "Preferred received packet size (msec)" θα ήταν άχρηστες αυτές οι βελτιώσεις του i-call και του evoice... Δεν ξέρω αν υπάρχει σε ΑΤΑ τέτοια επιλογή. Ή αν υπάρχει, αν ο server θα τις σεβαστεί. Μπερδεμένο πράμα...

Δοκιμάζοντας τελευταία με asterisk που έχει τέτοια επιλογή, δυστήχως ο server στην άλλη πλευρά το αγνοεί,

[cosmos]

Εννοείς ότι το αγνοεί το ata/client (δλδ η αντίπερα πλευρά του asterisk);

[sdikr]

Εννοείς ότι το αγνοεί το ata/client (δλδ η αντίπερα πλευρά του asterisk);

Ο αντίπερα server πχ το sipdicount

[anon]

H χρήση μικρών πακέτων έχει νόημα, μιας και δεν υπάρχει retransmit σε πακέτα rtp/udp οπότε εαν χαθεί κάποιο πακέτο, αυτο θα είναι λίγα msec. Βέβαια όταν έχεις πακετοπροβλήματα, οι προτεραιότητες αλλάζουν.... Ομως έξω δεν έχουν τέτοιο πρόβλημα, ή τουλάχιστον τόσο έντονο, οπότε είναι λογικό να προτιμούν μικρά πακέτα...Σωστή όμως η παρατήρηση ότι θα έπρεπε να "συμμορφώνεται" ο σερβερας στις προτιμήσεις του client.

[alala321]

O server θα μπορούσε να επέμβει σε επίπεδο SDP αλλά στο SDP αναφέρεται ο codec χωρίς να αναφέρονται οι ρυθμίσεις που συζητούνται (μέγεθος πακέτων...). Συνεπώς το ζήτημα ανάγεται σε επίπεδο υλοποίησης του codec στον SIP client, κατά πόσο δηλαδή ο SIP UA δίνει την δυνατότητα να σκαλιστούν οι ρυθμίσεις αυτές.

2 SIP users θα μπορούσαν να μιλήσουν χρησιμοποιώντας έναν τέτοιο παραμετροποιήσιμο client χωρίς να αντιμετωπίζουν το γνωστό πρόβλημα περιορισμού πακέτων, βάζοντας "καρφωτά" και οι δύο την ίδια "κατάλληλη" ρύθμιση για το μέγεθος πακέτων. Όλο και κάποιος Open Source SIP UA θα μπορούσε να χρησιμοποιηθεί γι΄αυτό το σκοπό... ;-) Εναλλακτικός τρόπος θα ήταν η χρήση ενός μηχανισμού διαπραγμάτευσης που μου διαφεύγει η ύπαρξή του αυτή την στιγμή.

Με αυτόν τον τρόπο δεν διαταράσεται η προδιαγεγραμμένη χρήση του SIP από άκρο σε άκρο και οι 2 users θα μπορούσαν πχ να μιλήσουν κρυπτογραφημένα χρησιμοποιώντας το Zfone (προτόκολο ZRTP), κάτι που μάλλον δεν ισχύει στην περίπτωση του i-call (με επιφύλαξη)

[cosmos]

O server θα μπορούσε να επέμβει σε επίπεδο SDP αλλά στο SDP αναφέρεται ο codec χωρίς να αναφέρονται οι ρυθμίσεις που συζητούνται (μέγεθος πακέτων...). Συνεπώς το ζήτημα ανάγεται σε επίπεδο υλοποίησης του codec στον SIP client, κατά πόσο δηλαδή ο SIP UA δίνει την δυνατότητα να σκαλιστούν οι ρυθμίσεις αυτές.
Διόρθωσε με αν κάνω λάθος, αλλά σε SDP με την ptime= μπορεί να δηλωθεί το μέγεθος των πακέτων που προτιμάς να λαμβάνεις. Στην πράξη, αν δεν κάνω λάθος, ο κάθε client ανακαλύπτει τι packetization interval του στέλνεται μετρώντας το payload και κάνοντας απλή μέθοδο των τριών (λ.χ. τα 20bytes g.729 αντιστοιχούν σε 20msec διάρκειας, τα 30 bytes που πήρα, σε πόσα; ).


2 SIP users θα μπορούσαν να μιλήσουν χρησιμοποιώντας έναν τέτοιο παραμετροποιήσιμο client χωρίς να αντιμετωπίζουν το γνωστό πρόβλημα περιορισμού πακέτων, βάζοντας "καρφωτά" και οι δύο την ίδια "κατάλληλη" ρύθμιση για το μέγεθος πακέτων. Όλο και κάποιος Open Source SIP UA θα μπορούσε να χρησιμοποιηθεί γι΄αυτό το σκοπό... ;-) Εναλλακτικός τρόπος θα ήταν η χρήση ενός μηχανισμού διαπραγμάτευσης που μου διαφεύγει η ύπαρξή του αυτή την στιγμή.
Μπορεί εν μέσω κλήσης να γίνει νέο SDP offer από οποιαδήποτε πλευρά, ώστε να ανεβάσει ή να κατεβάσει το packetization interval. Απαραίτητη προϋπόθεση βέβαια είναι να μπορεί να γίνει μια τέτοια αλλαγή (η οποία όμως αποτελεί afaik μέρος του SIP, άρα κάθε compliant UA έχει την λειτουργικότητα).

Η πλάκα είναι (πάλι αν το κατάλαβα σωστά) ότι υπάρχει ανεξαρτησία στις δύο κατευθύνσεις όσον αφορά το ptime. 20ms μπορεί να στέλνει ο ένας, 40 ο άλλος...

Εκείνο που δεν ξέρω είναι αν όλα τα clients υποστηρίζουν any-packetization. Λ.χ. στο Fritz έχω την ιδέα ότι υποστηρίζονται 20msec και 30msec. Πραγματικά στη γραμμή μου που έχω ψιλοπρόβλημα, σε i-call level 2 (αντίστοιχο 110msec) η ποιότητα ήταν μάπα. Βάζοντάς το στο off η ποιότητα έγινε απόλυτα ισοδύναμη με σταθερού (να μην πω και καλύτερη). Πρέπει να δω το επίπεδο 1 σε τι αντιστοιχεί.


Με αυτόν τον τρόπο δεν διαταράσεται η προδιαγεγραμμένη χρήση του SIP από άκρο σε άκρο και οι 2 users θα μπορούσαν πχ να μιλήσουν κρυπτογραφημένα χρησιμοποιώντας το Zfone (προτόκολο ZRTP), κάτι που μάλλον δεν ισχύει στην περίπτωση του i-call (με επιφύλαξη)
Υποθέτω (και μόνο) ότι κάτι τέτοιο θα έσκιζε το server ειδικά αν παίζει και transcoding.

Πάντως μου κάνουν εντύπωση μερικά πράγματα (ολίγον OT, αλλά όλο το thread έχει χαρακτήρα brainstorming):
1) Ακόμα και εμπορικός εξοπλισμός (λ.χ. Cisco) κάνει σαχλαμάρες με τα codec names που χρησιμοποιεί
2) Είναι τρομερά δύσκολο να βρεις ΑΤΑ κάτω από τα 100 - 150 ευρώ (και μακάρι να με διορθώσει κάποιος) που να υποστηρίζει πολλαπλά Voip registrations, ώστε να μπορείς να έχεις λ.χ. πολλαπλά voip numbers
3) Το SIP ως spec αφήνει πολλά παράθυρα -> φαντάζομαι ότι τα interop προβλήματα είναι πιο εύκολο να εμφανιστούν σε αυτό παρά σε H.323.

@sdikr: Για να καταλάβω, έστησες κάποιον Asterisk, ναι; Και τον έβαλες ως client ας πούμε για SIPDiscount. Και ρύθμισες ώστε να προτιμά μεγαλύτερα πακέτα (από 20msec) αλλά δεν παίρνεις τέτοια; Αν ναι, δώσε κανά log αν θες.

[alala321]

Διόρθωσε με αν κάνω λάθος, αλλά σε SDP με την ptime= μπορεί να δηλωθεί το μέγεθος των πακέτων που προτιμάς να λαμβάνεις.


Δεν σε διορθώνω γιατί έχεις δίκιο, η προηγούμενη τοποθέτησή μου βασίστηκε σε μια συζήτηση που είχα με κάποιον απο τo I-call στο υπόμνημα "i-Call: Δημοσίευση λύσης", περί SDP headers. Tώρα όμως έριξα μια ματιά στο RFC 2327 :rtfm: και πείστηκα περί SDP και ptime. Επείσης όταν παλιότερα είχα βάλει Ethereal για να δω τα SDP πακέτα, δεν είχα δει κάτι επειδή προφανώς όταν οι codecs παίζουν με τις default τιμές δεν χρειάζεται να αναφερθούν παράμετροι όπως ptime...

Αυτό που τώρα θα ήθελα να προσθέσω και πιστεύω ότι μπορεί να βοηθήσει την κατάσταση είναι ότι βρήκα UA που στις παραμέτρους του επιδέχεται σκαλίσματος για αυτά που συζητάμε, είναι ο eyeBeam

<edit> Αλλάζοντας το ptime στο eyeBeam, δεν φαίνεται κάτι αντίστοιχο στο SDP header του INVITE / ΟΚ
(!!! τελικά δεν σε αφήνει να αλλάξεις τις παραμέτρους το eyeBeam και τις επαναφέρει μόνο του στις αρχικές τιμές!!! )
Επείσης, απο το RFC: It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the
encoding/packetisation of audio. :hmm: Η ερώτηση μου προς cosmos είναι αν στις δοκιμές με το ATA ή Xlite είδες να μπαίνει το ptime στον SDP header (πχ. a=ptime 30) . Πάντως, μετά από ένα googling φαίνεται ότι η ύπαρξη του ptime δεν είναι δεσμευτική προς την άλλη μεριά και στο RFC αναφέρεται ως Suggested Attribute... Μάλλον το ζήτημα θα διευθετηθεί μελλοντικά (πχ στο draft draft-xu-mmusic-sdp-codec-param-01 προτείνεται και ptime negotiation) αλλά το θέμα είναι τι μπορούμε να κάνουμέ στο παρών

Πάντως είναι πολύ σπάνιο να υποστηρίζει ολόκληρο το SIP προτόκολο κάποιος UA σύμφωνα με τα specs (RFCs), παλιότερα προ 3ετίας που είχα εργαστεί επι του θέματος μου είχε κάνει εντύπωση το γεγονός οτι οι πιο πολλοί UAs υποστήριζαν τμηματικά το προτόκολο ενώ άλλοι είχαν "πατεντιάρικη" συμπεριφορά... Τότε η πιο πιστή υλοποίηση του προτοκόλου υπήρχε σε cisco-phone (7960?) χωρίς να μπορώ να πω τι συμβαίνει τώρα. Την πιο ληψή υλοποίηση την είχε ο MS messenger.
Το SIP πάντως είναι πολύ advanced προτόκολο, το VoIP είναι μόνο μια μικρή υποκατηγορία των δυνατοτήτων του.

Επειδή έχω δικό μου SIP server, είμαι ανοικτός σε οποιαδήποτε ιδέα, δοκιμή, κλπ

[cosmos]

Δεν σε διορθώνω γιατί έχεις δίκιο, η προηγούμενη τοποθέτησή μου βασίστηκε σε μια συζήτηση που είχα με κάποιον απο τo I-call στο υπόμνημα "i-Call: Δημοσίευση λύσης", περί SDP headers. Tώρα όμως έριξα μια ματιά στο RFC 2327 :rtfm: και πείστηκα περί SDP και ptime. Επείσης όταν παλιότερα είχα βάλει Ethereal για να δω τα SDP πακέτα, δεν είχα δει κάτι επειδή προφανώς όταν οι codecs παίζουν με τις default τιμές δεν χρειάζεται να αναφερθούν παράμετροι όπως ptime...
Αυτό που τώρα θα ήθελα να προσθέσω και πιστεύω ότι μπορεί να βοηθήσει την κατάσταση είναι ότι βρήκα UA που στις παραμέτρους του επιδέχεται σκαλίσματος για αυτά που συζητάμε, είναι ο eyeBeam

<edit> Αλλάζοντας το ptime στο eyeBeam, δεν φαίνεται κάτι αντίστοιχο στο SDP header του INVITE / ΟΚ
(!!! τελικά δεν σε αφήνει να αλλάξεις τις παραμέτρους το eyeBeam και τις επαναφέρει μόνο του στις αρχικές τιμές!!! )
Επείσης, απο το RFC: It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the
encoding/packetisation of audio. :hmm:
Καλό πράμα η υποστήριξη του ptime, άσχετα αν από την άλλη πλευρά δεν "μεταφράζεται" και πάντα. Αναρωτιέμαι αν το νέο x-lite έχει τέτοια λειτουργικότητα.


Η ερώτηση μου προς cosmos είναι αν στις δοκιμές με το ATA ή Xlite είδες να μπαίνει το ptime στον SDP header (πχ. a=ptime 30) .
Σε fritz όχι και σε X-lite (στο οποίο δηλώνεις payload σε bytes, αντίστοιχο του χρόνου για κάθε codec) όχι. Γενικά πολύ σπάνια το βλέπω. Κυρίως από την πλευρά server -> client

Πάντως, μετά από ένα googling φαίνεται ότι η ύπαρξη του ptime δεν είναι δεσμευτική προς την άλλη μεριά και στο RFC αναφέρεται ως Suggested Attribute... Μάλλον το ζήτημα θα διευθετηθεί μελλοντικά (πχ στο draft draft-xu-mmusic-sdp-codec-param-01 προτείνεται και ptime negotiation) αλλά το θέμα είναι τι μπορούμε να κάνουμέ στο παρών
Έχεις απόλυτο δίκιο... Ως χρήστες μπορούμε να καταγράψουμε enhancement requests για να στρώνουν σιγά - σιγά τα ΑΤΑ. Ως ιδιοκτήτες servers, αρκετών εκ των οποίων είναι και open source, enhancement requests (μια από τα ίδια δλδ).
[/COLOR]

Πάντως είναι πολύ σπάνιο να υποστηρίζει ολόκληρο το SIP προτόκολο κάποιος UA σύμφωνα με τα specs (RFCs), παλιότερα προ 3ετίας που είχα εργαστεί επι του θέματος μου είχε κάνει εντύπωση το γεγονός οτι οι πιο πολλοί UAs υποστήριζαν τμηματικά το προτόκολο ενώ άλλοι είχαν "πατεντιάρικη" συμπεριφορά... Τότε η πιο πιστή υλοποίηση του προτοκόλου υπήρχε σε cisco-phone (7960?) χωρίς να μπορώ να πω τι συμβαίνει τώρα. Την πιο ληψή υλοποίηση την είχε ο MS messenger.
Από ελάχιστη εμπειρία που έχω (η οποία είναι του τύπου hands-on για λίγη ώρα και debug logs), πολύ καλή δουλειά (καλή=conformant) φαίνεται να την κάνει η Draytek με τα Vigor. Cisco/Linksys/Sipura επιμένουν σε ιδιωματισμούς (πως "ονοματίζουν" λ.χ. στάνταρ codecs), αλλά κάνουν καλή δουλειά κατά τα άλλα όσον αφορά τη συμβατότητα με τα specs.


Το SIP πάντως είναι πολύ advanced προτόκολο, το VoIP είναι μόνο μια μικρή υποκατηγορία των δυνατοτήτων του.Όντως, βασικά παρέχει το control μιας επικοινωνίας, η οποία μπορεί να είναι οτιδήποτε (ήχος, εικόνα, data ...).


Επειδή έχω δικό μου SIP server, είμαι ανοικτός σε οποιαδήποτε ιδέα, δοκιμή, κλπΕυχαριστώ για την πρόθεση βοήθειας. Αν βρω λίγο χρόνο θα με ενδιέφεραν μερικά τεστάκια, αλλά ο χρόνος μου είναι είδος υπό διωγμόν τελευταία. Ποιον server έχεις;

[alala321]

O server είναι ο SIP Express Router 0.9.6-0.1 (SER) της IPTEL: http://www.iptel.org/ser/
σε Linux Debian Sarge 3.1 και τρέχει σε ένα ηρωικό PIII 450 το οποίο σπάνια ανοίγω γιατί κάνει φασαρία :)